On Mon, Nov 15, 2021 at 08:16:25PM +0100, Heinrich Schuchardt wrote: > On 11/15/21 20:05, Simon Glass wrote: > > Hi Takahiro, > > > > On Sun, 14 Nov 2021 at 18:43, AKASHI Takahiro > > <takahiro.aka...@linaro.org> wrote: > > > > > > Hi Simon, > > > > > > On Sat, Nov 13, 2021 at 02:32:20PM -0700, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.g...@gmx.de> > > > > wrote: > > > > > > > > > > Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass > > > > > <s...@chromium.org>: > > > > > > Hi, > > > > > > > > > > > > On Mon, 8 Nov 2021 at 17:09, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas > > > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi chiming in a little late but > > > > > > > > > > > > > > > > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro > > > > > > > > <takahiro.aka...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote: > > > > > > > > > > Hi Takahiro, > > > > > > > > > > > > > > > > > > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro > > > > > > > > > > <takahiro.aka...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt > > > > > > > > > > > > <xypron.g...@gmx.de> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/1/21 03:14, Simon Glass wrote: > > > > > > > > > > > > > > Hi Takahiro, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro > > > > > > > > > > > > > > <takahiro.aka...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 31, 2021 at 07:15:17PM -0600, Simon > > > > > > > > > > > > > > > Glass wrote: > > > > > > > > > > > > > > > > Hi Takahiro, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro > > > > > > > > > > > > > > > > <takahiro.aka...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Oct 30, 2021 at 07:45:14AM +0200, > > > > > > > > > > > > > > > > > Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 29. Oktober 2021 23:17:56 MESZ schrieb > > > > > > > > > > > > > > > > > > Simon Glass <s...@chromium.org>: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 29 Oct 2021 at 13:26, Heinrich > > > > > > > > > > > > > > > > > > > Schuchardt <xypron.g...@gmx.de> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 29. Oktober 2021 08:15:56 MESZ > > > > > > > > > > > > > > > > > > > > schrieb AKASHI Takahiro > > > > > > > > > > > > > > > > > > > > <takahiro.aka...@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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No. You can have a bare device without > > > > > > > > > > > > > > > > > > > > a partition table. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can have a DOS partition that covers > > > > > > > > > > > > > > > > > > > the whole device, without a > > > > > > > > > > > > > > > > > > > partition table. This is supported in > > > > > > > > > > > > > > > > > > > U-Boot and Linux. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have several partition table > > > > > > > > > > > > > > > > > > > > drivers: DOS, GPT, OSX, ... . In future > > > > > > > > > > > > > > > > > > > > we should also have one for the NOR > > > > > > > > > > > > > > > > > > > > Flash partitions. All of these drivers > > > > > > > > > > > > > > > > > > > > have a common interface. As the > > > > > > > > > > > > > > > > > > > > partition table type is mostly > > > > > > > > > > > > > > > > > > > > independent of the block device type we > > > > > > > > > > > > > > > > > > > > should use separate uclasses and > > > > > > > > > > > > > > > > > > > > udevices. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How hardware partitions, LUNs, ATA > > > > > > > > > > > > > > > > > > > > drives are enumerated is specific to > > > > > > > > > > > > > > > > > > > > the type of controller while the type > > > > > > > > > > > > > > > > > > > > of software partition table is > > > > > > > > > > > > > > > > > > > > independent of the block device. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |-- 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All these levels exist already. We > > > > > > > > > > > > > > > > > > > > simply do not model them yet in the DM > > > > > > > > > > > > > > > > > > > > way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The device tree depth is the outcome of > > > > > > > > > > > > > > > > > > > > the udevice exposing always only a > > > > > > > > > > > > > > > > > > > > single interface defined by the uclass. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The UEFI design allows installing > > > > > > > > > > > > > > > > > > > > multiple protocol interfaces on a > > > > > > > > > > > > > > > > > > > > single handle. This may result in > > > > > > > > > > > > > > > > > > > > simpler device trees in some cases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, the complexity has to go somewhere. > > > > > > > > > > > > > > > > > > > With driver model I chose to > > > > > > > > > > > > > > > > > > > have a single interface per uclass, since > > > > > > > > > > > > > > > > > > > it is simpler to understand, > > > > > > > > > > > > > > > > > > > no need to request a protocol for a > > > > > > > > > > > > > > > > > > > device, etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Our current setup is similar to this > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |-- Controller (UCLASS_MMC) > > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - > > > > > > > > > > > > > > > > > > > 'usual' HW partition > > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - > > > > > > > > > > > > > > > > > > > e.g. for a different HW partition* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * although I don't think the MMC code > > > > > > > > > > > > > > > > > > > actually supports it - SCSI does though > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want to add devices for the partition > > > > > > > > > > > > > > > > > > > table and the filesystem, so could do: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |-- Controller (UCLASS_MMC) > > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - > > > > > > > > > > > > > > > > > > > 'usual' HW partition (the whole device) > > > > > > > > > > > > > > > > > > > | | |-- Partition table (UCLASS_PART) - > > > > > > > > > > > > > > > > > > > DOS partition (or EFI) > > > > > > > > > > > > > > > > > > > | | | |-- Block device (UCLASS_BLK) - > > > > > > > > > > > > > > > > > > > partition 1 > > > > > > > > > > > > > > > > > > > | | | | |-- Filesystem (UCLASS_FS) - DOS > > > > > > > > > > > > > > > > > > > filesystem > > > > > > > > > > > > > > > > > > > | | | |-- Block device (UCLASS_BLK) - > > > > > > > > > > > > > > > > > > > partition 2 > > > > > > > > > > > > > > > > > > > | | | | |-- Filesystem (UCLASS_FS) - ext5 > > > > > > > > > > > > > > > > > > > filesystem > > > > > > > > > > > > > > > > > > > | |-- Block device (UCLASS_BLK) - > > > > > > > > > > > > > > > > > > > e.g. for a different HW > > > > > > > > > > > > > > > > > > > partition (the whole device) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is similar to Heinrich's, but > > > > > > > > > > > > > > > > > > > without the top-level > > > > > > > > > > > > > > > > > > > UCLASS_HW_PARTITION_TABLE which I am not > > > > > > > > > > > > > > > > > > > sure is necessary. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Are further MMC hw partitions, multiple > > > > > > > > > > > > > > > > > > SCSI LUNs and multiple NVME namespaces > > > > > > > > > > > > > > > > > > already treated as separate BLK devices? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > What I meant to say is that, if we don't need > > > > > > > > > > > > > > > > > a partition table 'udevice' > > > > > > > > > > > > > > > > > for hw partitions, we don't need such a > > > > > > > > > > > > > > > > > device for sw partitions neither. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Meanwhile, what about UCLASS_FS? Why do we > > > > > > > > > > > > > > > > > need this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We don't need it for our current discussion, > > > > > > > > > > > > > > > > but if we want to 'open' > > > > > > > > > > > > > > > > the filesystem and keep the metadata around, > > > > > > > > > > > > > > > > rather than reading it > > > > > > > > > > > > > > > > again every time we access a file, we might > > > > > > > > > > > > > > > > find it useful. Open files > > > > > > > > > > > > > > > > could be children of the FS uclass, perhaps, if > > > > > > > > > > > > > > > > we go a step further > > > > > > > > > > > > > > > > and create devices for them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you want to invent linux-like mount-point > > > > > > > > > > > > > > > concepts or procfs? > > > > > > > > > > > > > > > I remember that you didn't want to have child > > > > > > > > > > > > > > > nodes under BLK devices. > > > > > > > > > > > > > > > I'm getting confused about our goal. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think we are all a bit unsure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think BLK devices can have children, sorry if I > > > > > > > > > > > > > > said the wrong thing > > > > > > > > > > > > > > somewhere along the way. For example, a partition > > > > > > > > > > > > > > would be under a BLK > > > > > > > > > > > > > > device, or a FS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What should DM represent in U-Boot world? > > > > > > > > > > > > > > > > > > > > > > > > > > > > That is what we are trying to figure out. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think the minimum is to have a a way to represent > > > > > > > > > > > > > > partitions (s/w > > > > > > > > > > > > > > and hw/). As I understand it, that's what we've > > > > > > > > > > > > > > been discussing. > > > > > > > > > > > > > > > > > > > > > > > > > > The discovery of hardware partitions is specific to > > > > > > > > > > > > > the block device > > > > > > > > > > > > > controller SCSI/MMC/ATA/NVMe. We currently do not > > > > > > > > > > > > > provide any > > > > > > > > > > > > > manipulation commands to create hardware partitions > > > > > > > > > > > > > (e.g. NVMe > > > > > > > > > > > > > namespaces, SCSI LUNs). This is why extracting a > > > > > > > > > > > > > uclass for hardware > > > > > > > > > > > > > partitions does not seem necessary. > > > > > > > > > > > > > > > > > > > > > > > > I can see the reasoning here. It might not stand the > > > > > > > > > > > > test of time but > > > > > > > > > > > > how about we go with it for now? For MMC hardware > > > > > > > > > > > > partition we would > > > > > > > > > > > > just end up with multiple BLK devices, like we do with > > > > > > > > > > > > SCSI LUNs at > > > > > > > > > > > > present, which seems like it should work (with some > > > > > > > > > > > > code tweaks). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Software partitioning (MBR, GPT, ...) is independent > > > > > > > > > > > > > of the harboring > > > > > > > > > > > > > block device. > > > > > > > > > > > > > > > > > > > > > > > > > > We already have a set of drivers for software > > > > > > > > > > > > > partition tables in disk/. > > > > > > > > > > > > > Currently the available methods of the drivers are > > > > > > > > > > > > > defined in > > > > > > > > > > > > > U_BOOT_PART_TYPE referring to struct part_driver. > > > > > > > > > > > > > > > > > > > > > > > > > > Currently struct part_driver knows only the following > > > > > > > > > > > > > methods: > > > > > > > > > > > > > > > > > > > > > > > > > > - get_info() > > > > > > > > > > > > > - print() > > > > > > > > > > > > > - test() > > > > > > > > > > > > > > > > > > > > > > > > > > These drivers should be ome a uclass. > > > > > > > > > > > > > > > > > > > > > > > > > > gpt.c and mbr.c allow to create and delete > > > > > > > > > > > > > partitions. I think we should add > > > > > > > > > > > > > > > > > > > > > > > > > > - create_partition() > > > > > > > > > > > > > - delete_partition() > > > > > > > > > > > > > > > > > > > > > > > > > > to the uclass methods. > > > > > > > > > > > > > > > > > > > > > > > > That sounds good to me, although since it is a > > > > > > > > > > > > partition uclass, we > > > > > > > > > > > > can just use create() and delete(). > > > > > > > > > > > > > > > > > > > > > > I don't know why we need a "partition table" device in > > > > > > > > > > > the middle > > > > > > > > > > > of DM hierarchy. > > > > > > > > > > > I believe that it simply makes the view of DM tree > > > > > > > > > > > complicated > > > > > > > > > > > without any explicit benefit. > > > > > > > > > > > > > > > > > > > > Well we clearly have an API here. The partition uclass can: > > > > > > > > > > > > > > > > > > > > - hold the partition table in dev_get_uclass_priv() > > > > > > > > > > - support a read() operation to read the partition > > > > > > > > > > - support create() to rewrite the partition table > > > > > > > > > > - support delete() to overwrite/erase the partition table > > > > > > > > > > > > > > > > > > > > Then it means that filesystems have the partition table as > > > > > > > > > > a parent > > > > > > > > > > (unless they are whole-device filesystems), which makes > > > > > > > > > > sense > > > > > > > > > > > > > > > > > > > > So that's why I like the idea. > > > > > > > > > > > > > > > > > > > > Other than the extra complexity, is there anything else > > > > > > > > > > wrong with it? > > > > > > > > > > > > > > > > > > - First of all, a partition table doesn't look like a > > > > > > > > > 'device' at all. > > > > > > > > > - Second, a partition table is just static data for block > > > > > > > > > devices. > > > > > > > > > IMO, even if we want to have this data, we can simply hold > > > > > > > > > it > > > > > > > > > as some sort of attribute of the device, or maybe as a > > > > > > > > > 'tag' which > > > > > > > > > I will introduce in the next version. > > > > > > > > > > > > > > > > > > -Takahiro Akashi > > > > > > > > > > > > > > > > > > > > > > > > > I don't know how this affect the code, but I agree with > > > > > > > > Akashi-san > > > > > > > > here. It's indeed useful to keep the partition table stored > > > > > > > > somewhere, but I think not showing them as part of the device > > > > > > > > tree is > > > > > > > > more intuitive. > > > > > > > > > > > > > > Well I think I'm easy either way. I just thought that Heinrich > > > > > > > made a > > > > > > > good case for having a partition uclass. > > > > > > > > > > > > > > But as Takahiro says, we can use a tag to attach the partition > > > > > > > table > > > > > > > to the device. But it should be attached to the device's children > > > > > > > (the > > > > > > > BLK device) not the media device itself, right? > > > > > > > > > > > > As there has been no discussion in 5 days and Takahiro is writing > > > > > > this, let's go with no uclass for the partition table. > > > > > > > > > > > > > > > > Without uclass you cannot bring the partition table drivers into th > > > > > driver model. > > > > > > This transition may be able to be done later when really necessary > > > as long as we agree that a partition table be hold within a "raw" disk > > > object (with a tag support). > > > # I don't think we need it for now. > > > > > > > > No clue what a tag should be in the driver model. > > > > > > > > A tag is a way to associate data with a device. At present we do this > > > > with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.) > > > > but with tags you can add something else. > > > > > > Since this discussion thread is getting too long, I would like > > > to respin my RFC. How should I deal with your "event notification" > > > proposal? > > > > Is the patch good enough to include in the series? > > > > If not, you could reply to it with what needs doing.
? I have already replied to your patch :) Basically, it seems to be fine to me. > > Regards, > > Simon > > > The patch is not usable as is. It assumes only GPT partioning is used. @Heinrich I don't get your point. Either my patch or Simon's is not specific to GPT at all. So I'm going to start respinning my patch for a next round of discussion. -Takahiro Akashi > Instead all partition table drivers need to be converted to drivers for > the new uclass. > > Best regards > > Heinrich
