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