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

AKASHI Takahiro
2021-10-29T06:16:13Z

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