[RFC 07/22] dm: blk: add UCLASS_PARTITION

[Heinrich Schuchardt]

Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass <sjg at chromium.org>:
>Hi,
>
>On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>>
>>
>> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro <takahiro.akashi at linaro.org>:
>> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
>> >>
>> >>
>> >> > I agree with Heinrich that we are better to leave BLK as it is, both
>> >> > in name and meaning. I think maybe I am missing the gist of your
>> >> > argument.
>> >> >
>> >> > If we use UCLASS_PART, for example, can we have that refer to both s/w
>> >> > and h/w partitions, as Herinch seems to allude to below? What would
>> >> > the picture look like the, and would it get us closer to agreement?
>> >>
>> >> In the driver model:
>> >>
>> >> A UCLASS is a class of drivers that share the same interface.
>> >> A UDEVICE is a logical device that belongs to exactly one UCLASS and is
>> >> accessed through this UCLASS's interface.
>> >
>> >Please be careful about "accessed through" which is a quite confusing
>> >expression. I don't always agree with this view.
>> >
>> >> A hardware partition is an object that exposes only a single interface
>> >> for block IO.
>> >>
>> >> A software partition is an object that may expose two interfaces: one
>> >> for block IO, the other for file IO.
>> >
>> >Are you talking about UEFI world or U-Boot?
>> >Definitely, a hw partitions can provide a file system
>> >if you want.
>> >It's a matter of usage.
>> >
>> >I remember that we had some discussion about whether block devices
>> >on UEFI system should always have a (sw) partition table or not.
>> >But it is a different topic.
>> >
>> >> The UEFI model does not have a problem with this because on a handle you
>> >> can install as many different protocols as you wish. But U-Boot's driver
>> >> model only allows a single interface per device. Up to now U-Boot has
>> >> overcome this limitation by creating child devices for the extra interfaces.
>> >
>> >> We have the following logical levels:
>> >>
>> >> Controller      | Block device | Software Partition| File system
>> >> ----------------+--------------+-------------------+------------
>> >> NVMe Drive      | Namespace    | Partition 1..n    | FAT, EXT4
>> >> ATA Controller  | ATA-Drive    |                   |
>> >> SCSI Controller | LUN          |                   |
>> >> MMC Controller  | HW-Partition |                   |
>> >> MMC Controller  | SD-Card      |                   |
>> >> USB-Node        | USB-Drive    |                   |
>> >>
>> >> In the device tree this could be modeled as:
>> >>
>> >> |-- Controller (UCLASS_CTRL)
>> >> | |-- Block device / HW Partition (UCLASS_BLK)    (A)
>> >> | | |-- Partition table (UCLASS_PARTITION_TABLE)  (B)
>> >> | |   |-- Software Partition (UCLASS_BLK)
>> >> | |     |-- File system (UCLASS_FS)
>> >> | |
>> >> | |-- Block device (UCLASS_BLK)
>> >> |   |-- File system (UCLASS_FS)
>> >
>> >I don't know why we expect PARTITION_TABLE and FS to appear in DM tree.
>> >What is the benefit?
>> >(A) and (B) always have 1:1 relationship.
>>
>> No. You can have a bare device without a partition table.
>
>I can have a DOS partition that covers the whole device, without a
>partition table. This is supported in U-Boot and Linux.
>
>>
>> We have several partition table drivers: DOS, GPT, OSX, ... . In future we should also have one for the NOR Flash partitions. All of these drivers have a common interface. As the partition table type is mostly independent of the block device type we should use separate uclasses and udevices.
>>
>> >I also remember that you claimed that not all efi objects(handles and
>> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding
>> >U-Boot counterparts in our 2019 discussion.
>> >
>> >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE,
>> >which should support other type of hw partitions as well?
>>
>> How hardware partitions, LUNs, ATA drives are enumerated is specific to the type of controller while the type of software partition table  is independent of the block device.
>>
>> >
>> >|-- eMMC controller (UCLASS_MMC)
>> >| |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?)
>> >|   |-- Block device / HW Partition:user data (UCLASS_BLK)
>> >|   | |-- Partition table (UCLASS_PARTITION_TABLE)
>> >|   |   |-- Software Partition (UCLASS_BLK)
>> >|   |     |-- File system (UCLASS_FS)
>> >|   |
>> >|   |-- Block device / HW Partition:boot0 (UCLASS_BLK)
>> >|   |-- Block device / HW Partition:boot1 (UCLASS_BLK)
>> >          ...
>> >| |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?)
>> >
>> >|-- scsi controller (UCLASS_SCSI)
>> >| |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?)
>> >|   |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?)
>> >|   | |-- Partition table (UCLASS_PARTITION_TABLE)
>> >|   |   |-- Software Partition (UCLASS_BLK)
>> >|   |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?)
>> >          ...
>> >
>> >(Here I ignored scsi buses/channels which make things more complicated.)
>> >
>> >This kind of complex hierarchy doesn't benefit anybody.
>>
>> All these levels exist already. We simply do not model them yet in the DM way.
>>
>> The device tree depth is the outcome of the udevice exposing always only a single interface defined by the uclass.
>>
>> The UEFI design allows installing multiple protocol interfaces on a single handle. This may result in simpler device trees in some cases.
>
>Yes, the complexity has to go somewhere. With driver model I chose to
>have a single interface per uclass, since it is simpler to understand,
>no need to request a protocol for a device, etc.
>
>Our current setup is similar to this
>
>|-- Controller (UCLASS_MMC)
>| |-- Block device (UCLASS_BLK)     - 'usual' HW partition
>| |-- Block device (UCLASS_BLK)     - e.g. for a different HW partition*
>
>* although I don't think the MMC code actually supports it - SCSI does though
>
>We want to add devices for the partition table and the filesystem, so could do:
>
>|-- Controller (UCLASS_MMC)
>| |-- Block device (UCLASS_BLK)     - 'usual' HW partition (the whole device)
>| | |-- Partition table (UCLASS_PART)  - DOS partition (or EFI)
>| | | |-- Block device (UCLASS_BLK)  - partition 1
>| | | | |-- Filesystem (UCLASS_FS) - DOS filesystem
>| | | |-- Block device (UCLASS_BLK)  - partition 2
>| | | | |-- Filesystem (UCLASS_FS) - ext5 filesystem
>| |-- Block device (UCLASS_BLK)     - e.g. for a different HW
>partition (the whole device)
>
>This is similar to Heinrich's, but without the top-level
>UCLASS_HW_PARTITION_TABLE which I am not sure is necessary.

Are further MMC hw partitions, multiple SCSI LUNs and multiple NVME  namespaces already treated as separate BLK devices?

Regards

Heinrich 


>
>It is compatible with what we have now and we could enable/disable the
>extra devices with a Kconfig.
>
>Regards,
>Simon
>
>
>
>> >
>> >> UCLASS_PARTITION_TABLE would be for the drivers in disk/.
>> >> UCLASS_FS would be for the drivers in fs/.
>> >> UCLASS_BLK will be for any objects exposing raw block IO. A software
>> >> partition does the same. It is created by the partition table driver as
>> >> child of the partition table udevice.
>> >>
>> >> In this model an eMMC device will not be a UCLASS_BLK device because it
>> >> does not expose block IO. It is the hardware partition that exposes this
>> >> interface.
>> >>
>> >> The suggested model will allow a clean description of nested partition
>> >> tables.
>> >>
>> >> In the UEFI world the software partition and its file system must be
>> >> mapped to a single handle with device path node type HD(). For the
>> >> parent block device we may create a child handle with partition number 0
>> >> (HD(0)). For the partition table we will not create a handle.
>> >>
>> >> Best regards
>> >>
>> >> Heinrich