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. 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. 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) | | |-- Partition table (UCLASS_PARTITION_TABLE) | | |-- Software Partition (UCLASS_BLK) | | |-- File system (UCLASS_FS) | | | |-- Block device (UCLASS_BLK) | |-- File system (UCLASS_FS) 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
