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

[AKASHI Takahiro <takahiro.akashi@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.
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?

|-- 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.

-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