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

[Heinrich Schuchardt]

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.

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.

Best regards
Heinrich 

>
>-Takahiro Akashi
>
>> 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