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. Regards, Simon