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