From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F341FC433F5 for ; Mon, 15 Nov 2021 19:16:41 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 650C460C4A for ; Mon, 15 Nov 2021 19:16:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 650C460C4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 75C028378D; Mon, 15 Nov 2021 20:16:39 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=gmx.net header.i=@gmx.net header.b="AqtQmPwn"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id ABCCC8370C; Mon, 15 Nov 2021 20:16:37 +0100 (CET) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 25DE28378D for ; Mon, 15 Nov 2021 20:16:33 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637003790; bh=B2Tr2c1ayWDtGz8gmG/QY5SB8ajrNHgjhDrS040ZMyU=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=AqtQmPwnA3y03HnxgH2GAF3tqY7+x+vj54zYsjaMOPnwzs7iCDZ6h7uw7FsbPWTFV S7/jQVUOMjVSS7m7Vu8cnnzZTmkEqWauvqwPZqYPXussCOMVccUMrTKuy3G7ozNuCN 3Nr0wGLO1W7P+vJKIwBRgqCQ/H0fS5a3QdkpTtYY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.55] ([88.152.144.157]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MrQIv-1mIXer2ebn-00oWtt; Mon, 15 Nov 2021 20:16:30 +0100 Message-ID: <938593ce-c7fb-57a2-0294-3f21354d48a0@gmx.de> Date: Mon, 15 Nov 2021 20:16:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION Content-Language: en-US To: Simon Glass , AKASHI Takahiro , Ilias Apalodimas , Tom Rini , U-Boot Mailing List , Alex Graf References: <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> <20211105024929.GD27316@laputa> <20211108044637.GD16401@laputa> <20211115014319.GA38596@laputa> From: Heinrich Schuchardt In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:aGP4FnpxJzRsNQ15ExYe3kw1gU7hmyEZW+eveiAu8Ci/BISYKli 4ZFIYxA5mrufUIMKe7s7Q8QYkleFRir6ZtaECi/QUSf2GPq9ljDe4BKX58Uoqnu//PWVM5b CxHED20aekcvzyu8DWelqpRCq/9AKxFnlh2/kVkyDoWoKyU89sheVRel575Vg7EDuRifSS2 O96FVOFyYn0G3tWjFX+qA== X-UI-Out-Filterresults: notjunk:1;V03:K0:84SlGV4E2aE=:bZ4sm7LywneiMxktaFnA4P SWB4MC/zaTmHOGyuHAT76wappVy7Iu5TJlihd7rsBuWCVykXlQoK9fIUlFWkEbTAHLINmMqr0 z2Vu3SCLZ3TLvJC7qJOL2ri2xznBPtqw5qOfe/oZSZUUJeBvSFUHaKF6fQ3VHsa1/gX2aDBDm Z+rPo8xIjuLqys6KUntwzAMMmqJBLn7Lhxuw/0Z82OWoguqgBZiKzr1Ro8aQxBsDCq8wDANjT i68ojStJeKOzLYk9e/t4l1J4Bi2cYumki2os93mS0o3oDSvKABS51GR2YWOR7C+HMo1Vg0Nhq dv/U3mmnzKvZeuOIHLnBlM/a8EQoM00LzsbOBqraT9Efzg68/HwOObtWJO40q27NY5t50KABx 9zsYKQdQBX7ZUUdKTo86k0YT25to33xyeWvLr4g4902uDWUNgi34B/bS7VVI6q3Nt4UXWwGEZ 6sqDKDp+/4GFWT3AIy7gkLuI+hdQdEXfiZVnicsphfFVV2axGWfm74FPIH7tPTFYrDowpunvJ DMKTAhznYgIdUI8xyVYlbB2K0DjupqSqgLiPGAMmPVOD4Iv+n9lN+JoK5xiCQT6dDj9bD/kuw WVjE77w1MY7vrBV8fWe04MTKwWvOJLQWZAln46yvjXNkxTgyeHfFssvisBCH++0syaJupSQI9 H9ZmU+jaJlLKVZdgxpLM496BB83y05bE+g6crAD38GY7ye/ECkE8asjznNjNQZriw3UHE+xdG I6pdcvskYeT/BGpQ2YBCpLU+s9KD7qw70jcbtE9yfm1HCBwGflGO2f7femxU1MY+vilmxslHH CZVuMOUrfGKiDDR7WcaXQgte7Ps8dZkFdmiHe/maaCyKTKavsx8LchNz2KJ4Pt7rEgY54smwr TNCN5i5KCIKGGICnOGAdwJWuyIrY9BO5+dWEvjVovYOmX5lrzh3bpBKpYgP3Hjn+6hHBjHQZr Lj+KVyeIVPuMaAJdT05jjcQB4JTjQ+YLFoH1PxGjXikHU0aEgJNqLRCnNXIhfx6BYwT8TPn5u OxTxfGhg2NLQiqovLAT74cNgFGVsPtQ7M2Iw6ksdKxixUe7AKmPUvpuO+onO+2L3orIAK2Ons Qtp3nWk0P2hOdA= X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.35 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 11/15/21 20:05, Simon Glass wrote: > Hi Takahiro, > > On Sun, 14 Nov 2021 at 18:43, AKASHI Takahiro > 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 = wrote: >>>> >>>> Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass : >>>>> Hi, >>>>> >>>>> On Mon, 8 Nov 2021 at 17:09, Simon Glass wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas >>>>>> wrote: >>>>>>> >>>>>>> Hi chiming in a little late but >>>>>>> >>>>>>> On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro 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 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 wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/1/21 03:14, Simon Glass wrote: >>>>>>>>>>>>> Hi Takahiro, >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro >>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuch= ardt wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass : >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takah= iro : >>>>>>>>>>>>>>>>>>>> On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Sc= huchardt wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I agree with Heinrich that we are better to leave B= LK 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 tha= t refer to both s/w >>>>>>>>>>>>>>>>>>>>>> and h/w partitions, as Herinch seems to allude to b= elow? What would >>>>>>>>>>>>>>>>>>>>>> the picture look like the, and would it get us clos= er to agreement? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In the driver model: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> A UCLASS is a class of drivers that share the same i= nterface. >>>>>>>>>>>>>>>>>>>>> A UDEVICE is a logical device that belongs to exactl= y 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 tw= o 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 ta= ble or not. >>>>>>>>>>>>>>>>>>>> But it is a different topic. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The UEFI model does not have a problem with this bec= ause 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 f= or 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 tab= le. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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. Al= l of these drivers have a common interface. As the partition table type is= mostly independent of the block device type we should use separate uclass= es and udevices. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I also remember that you claimed that not all efi obj= ects(handles and >>>>>>>>>>>>>>>>>>>> protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to ha= ve corresponding >>>>>>>>>>>>>>>>>>>> U-Boot counterparts in our 2019 discussion. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If we *need* PARTITION_TALBLE, why don't we have HW_P= ARTITION_TABLE, >>>>>>>>>>>>>>>>>>>> which should support other type of hw partitions as w= ell? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> How hardware partitions, LUNs, ATA drives are enumerat= ed is specific to the type of controller while the type of software partit= ion table is independent of the block device. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> |-- eMMC controller (UCLASS_MMC) >>>>>>>>>>>>>>>>>>>> | |-- eMMC device1 / Physical media (UCLASS_HW_PARTIT= ION_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_PARTIT= ION_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 anybod= y. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 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 ex= posing always only a single interface defined by the uclass. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The UEFI design allows installing multiple protocol in= terfaces on a single handle. This may result in simpler device trees in so= me cases. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yes, the complexity has to go somewhere. With driver mo= del 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 partit= ion >>>>>>>>>>>>>>>>>> | |-- Block device (UCLASS_BLK) - e.g. for a differ= ent 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 partit= ion (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 differ= ent HW >>>>>>>>>>>>>>>>>> partition (the whole device) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is similar to Heinrich's, but without the top-leve= l >>>>>>>>>>>>>>>>>> UCLASS_HW_PARTITION_TABLE which I am not sure is necess= ary. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Are further MMC hw partitions, multiple SCSI LUNs and mu= ltiple 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 par= titions neither. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Meanwhile, what about UCLASS_FS? Why do we need this? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We don't need it for our current discussion, but if we wan= t to 'open' >>>>>>>>>>>>>>> the filesystem and keep the metadata around, rather than r= eading 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 st= ep further >>>>>>>>>>>>>>> and create devices for them. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you want to invent linux-like mount-point concepts or pr= ocfs? >>>>>>>>>>>>>> I remember that you didn't want to have child nodes under B= LK 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 w= rong thing >>>>>>>>>>>>> somewhere along the way. For example, a partition would be u= nder 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 partitio= ns (s/w >>>>>>>>>>>>> and hw/). As I understand it, that's what we've been discuss= ing. >>>>>>>>>>>> >>>>>>>>>>>> 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. NVM= e >>>>>>>>>>>> namespaces, SCSI LUNs). This is why extracting a uclass for h= ardware >>>>>>>>>>>> partitions does not seem necessary. >>>>>>>>>>> >>>>>>>>>>> I can see the reasoning here. It might not stand the test of t= ime 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 LU= Ns at >>>>>>>>>>> present, which seems like it should work (with some code tweak= s). >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Software partitioning (MBR, GPT, ...) is independent of the h= arboring >>>>>>>>>>>> block device. >>>>>>>>>>>> >>>>>>>>>>>> We already have a set of drivers for software partition table= s 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 thin= k we should add >>>>>>>>>>>> >>>>>>>>>>>> - create_partition() >>>>>>>>>>>> - delete_partition() >>>>>>>>>>>> >>>>>>>>>>>> to the uclass methods. >>>>>>>>>>> >>>>>>>>>>> That sounds good to me, although since it is a partition uclas= s, we >>>>>>>>>>> can just use create() and delete(). >>>>>>>>>> >>>>>>>>>> I don't know why we need a "partition table" device in the midd= le >>>>>>>>>> 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 par= ent >>>>>>>>> (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 wi= th 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' w= hich >>>>>>>> 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 tre= e 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 tabl= e >>>>>> 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 d= river 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 > The patch is not usable as is. It assumes only GPT partioning is used. Instead all partition table drivers need to be converted to drivers for the new uclass. Best regards Heinrich