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 9FB21C433EF for ; Sat, 13 Nov 2021 18:37:12 +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 C8D3560EFE for ; Sat, 13 Nov 2021 18:37:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C8D3560EFE 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 CDAAE83014; Sat, 13 Nov 2021 19:37:09 +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="Qh7h3mXI"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 78D0A83072; Sat, 13 Nov 2021 19:37:08 +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 31F0382F9B for ; Sat, 13 Nov 2021 19:37:03 +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=1636828620; bh=od4AUnuFoPfTyaRWCqzKC+zY9CJS5oZRD6Uce8WOS8c=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=Qh7h3mXIsTRZzLjW1/klLKEAzT/9I/1dAsFlhG8VNqojOmUDUdfitSlZ32ViCcZDM zWnncJe0hY7/2ISyP/dpzjgaPKudJ931sXQWZ85YeUh1PcKlaurPbjZ0ircWepaGDn gvE1dzGuhjsgb6Yk98Z+nAxrDixFAhTCqati01RI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([88.152.144.157]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mwwdl-1mTDvT2ap1-00yPE0; Sat, 13 Nov 2021 19:37:00 +0100 Date: Sat, 13 Nov 2021 19:37:01 +0100 From: Heinrich Schuchardt To: Simon Glass , Ilias Apalodimas CC: AKASHI Takahiro , Tom Rini , U-Boot Mailing List , Alex Graf Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION User-Agent: K-9 Mail for Android In-Reply-To: References: <20211101003600.GB25300@laputa> <20211101015155.GC25300@laputa> <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> <20211105024929.GD27316@laputa> <20211108044637.GD16401@laputa> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:R7OWbDj1EgwG35X2kINWkHVHCJL9UlgeSw62jkPVcZs4EhhZU47 NgXBn67UqQzb6Ke3x2ivYvU4JbfaUPvyS2nMtgpJrAkLouc5tYAaRldTjx64rKnC3sCB5sk tq1gvQqTBDGxHphFA+RM+63n+lpYy5R2ZzgyeyFvgvAElJmpH/Mol2p+Xxe1AP49jygChV1 A72iZTpIvaHNHHPyVuyVw== X-UI-Out-Filterresults: notjunk:1;V03:K0:xwCZVVDJWo4=:X7hq/kGuq+R8cdzNwX1b3K 4EH2sn3/uILKik7Dr8Npme5esgKio29vCUZGHmQVs4QuJUrLoFi4UB/L3qTZj89fLHtY9A2Jg 5yysFOoxoABGGmYaLG0FEmRrsJuox4SjCnNGUw3XvzeSdygegBRAHcocPv7cvz2o6t4WCkm0m uB79JFVNdPqonOGSFMpP1ufwQAOsieV5AYihwvFaP+1laGRkqqkbexjGMn7Xd3XOpFqJsxXpr fDkV9LwUX9p5Td13lleWqcwTcbIIz0uPLurN8KaRhqcsw+Chrj9rhi7llZdbmZYxzfRG5DcH8 I1Xz0nhfe2lqxL+i5oAED2/CqHB1gADOCGiHP6/jjxww4Lh1OHB3PYJ2nlowNpXM2Zz5mcdXe Iujitr3/7eMNrhBrBsOPzTzEA+iT3xSUbNJC5oXi2vlIPj5I9tdyGhBWm6D46iyd+0GdHzpnD D1kE49itdEssBJXO+WawRm2+BKpM9AiaykNt6giU1aaKVRMe0dvgtYHzdeVEEWKkotPQGVcLC FYVb5c6PyxO05RJNyBQGXqGYCqP08puGERxqIN3XPa7QX2tQE6Znh+joLPmmQ8DRy+PZit0CU uz+oeCWfzsm8RAdxFnDzEyKd6lzC6gJ3VztzkmN6EV7CvnLFtl72TQt85+YKwKzd+gwOHwvLr S2K7U7UndolpZqbeiFsb643a6m6ULi8Hi3w9VVyOy27ziEBQbEXVrU7/YhcI0RjjfbsaswVed ipk9jNj1PgrD7fGIE+ubBI5Oe5ZCmHWxk65Un7JF9TWH+xSMWbSTxzuVmWlxxSr4Ll8CkCH7n 5Svnou7BgtTDNTyotTD9xlIFuspVpKxZItlS4tPwI5Np9qeb8NE8H8LiNay5FpXq+k1Vwa4oB 6YtJ8bQON3iGwKylCB+muUDdoj1JywssVfDFDOzMNfyyeNitnmYzFTL/MGvxRD1qQ8YUpaKKi sw2AD3mzP/CE9DpebwhwILxkFqT5VfDnWpcGeGSTkvgFXrrl2p0kENMtd0iSRsC/1v2mvJVIP cF0q7hSr2qrQihSvICoHJUbQjaV5FDykvd8WFkpkdUl81OyUqmEmj5I9bAogu0TdcUEWkAKd4 iCBVgFuEEorcvE= 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 Am 13=2E 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 wr= ote: >> > > > > > > >>> Hi Takahiro, >> > > > > > > >>> >> > > > > > > >>> On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro >> > > > > > > >>> wrote: >> > > > > > > >>>> >> > > > > > > >>>> On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Sch= uchardt wrote: >> > > > > > > >>>>> >> > > > > > > >>>>> >> > > > > > > >>>>> Am 29=2E Oktober 2021 23:17:56 MESZ schrieb Simon Gla= ss : >> > > > > > > >>>>>> Hi, >> > > > > > > >>>>>> >> > > > > > > >>>>>> On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt wrote: >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> Am 29=2E Oktober 2021 08:15:56 MESZ schrieb AKASHI = Takahiro : >> > > > > > > >>>>>>>> On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich= Schuchardt wrote: >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>>> I agree with Heinrich that we are better to leav= e BLK as it is, both >> > > > > > > >>>>>>>>>> in name and meaning=2E I think maybe I am missin= g the gist of your >> > > > > > > >>>>>>>>>> argument=2E >> > > > > > > >>>>>>>>>> >> > > > > > > >>>>>>>>>> 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 t= o below? What would >> > > > > > > >>>>>>>>>> the picture look like the, and would it get us c= loser to agreement? >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> In the driver model: >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> A UCLASS is a class of drivers that share the sam= e interface=2E >> > > > > > > >>>>>>>>> A UDEVICE is a logical device that belongs to exa= ctly one UCLASS and is >> > > > > > > >>>>>>>>> accessed through this UCLASS's interface=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> Please be careful about "accessed through" which i= s a quite confusing >> > > > > > > >>>>>>>> expression=2E I don't always agree with this view= =2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>>> A hardware partition is an object that exposes on= ly a single interface >> > > > > > > >>>>>>>>> for block IO=2E >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> A software partition is an object that may expose= two interfaces: one >> > > > > > > >>>>>>>>> for block IO, the other for file IO=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> Are you talking about UEFI world or U-Boot? >> > > > > > > >>>>>>>> Definitely, a hw partitions can provide a file sys= tem >> > > > > > > >>>>>>>> if you want=2E >> > > > > > > >>>>>>>> It's a matter of usage=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> I remember that we had some discussion about wheth= er block devices >> > > > > > > >>>>>>>> on UEFI system should always have a (sw) partition= table or not=2E >> > > > > > > >>>>>>>> But it is a different topic=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>>> The UEFI model does not have a problem with this = because on a handle you >> > > > > > > >>>>>>>>> can install as many different protocols as you wi= sh=2E But U-Boot's driver >> > > > > > > >>>>>>>>> model only allows a single interface per device= =2E Up to now U-Boot has >> > > > > > > >>>>>>>>> overcome this limitation by creating child device= s for the extra interfaces=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>>> We have the following logical levels: >> > > > > > > >>>>>>>>> >> > > > > > > >>>>>>>>> Controller | Block device | Software Partiti= on| File system >> > > > > > > >>>>>>>>> ----------------+--------------+-----------------= --+------------ >> > > > > > > >>>>>>>>> NVMe Drive | Namespace | Partition 1=2E= =2En | 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=2E >> > > > > > > >>>>>>>> What is the benefit? >> > > > > > > >>>>>>>> (A) and (B) always have 1:1 relationship=2E >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> No=2E You can have a bare device without a partitio= n table=2E >> > > > > > > >>>>>> >> > > > > > > >>>>>> I can have a DOS partition that covers the whole dev= ice, without a >> > > > > > > >>>>>> partition table=2E This is supported in U-Boot and L= inux=2E >> > > > > > > >>>>>> >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> We have several partition table drivers: DOS, GPT, = OSX, =2E=2E=2E =2E In future we should also have one for the NOR Flash part= itions=2E All of these drivers have a common interface=2E As the partition = table type is mostly independent of the block device type we should use sep= arate uclasses and udevices=2E >> > > > > > > >>>>>>> >> > > > > > > >>>>>>>> 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=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> If we *need* PARTITION_TALBLE, why don't we have H= W_PARTITION_TABLE, >> > > > > > > >>>>>>>> which should support other type of hw partitions a= s well? >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> How hardware partitions, LUNs, ATA drives are enume= rated is specific to the type of controller while the type of software part= ition table is independent of the block device=2E >> > > > > > > >>>>>>> >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> |-- eMMC controller (UCLASS_MMC) >> > > > > > > >>>>>>>> | |-- eMMC device1 / Physical media (UCLASS_HW_PAR= TITION_TABLE?) >> > > > > > > >>>>>>>> | |-- Block device / HW Partition:user data (UCL= ASS_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) >> > > > > > > >>>>>>>> =2E=2E=2E >> > > > > > > >>>>>>>> | |-- eMMC device2 / Physical media (UCLASS_HW_PAR= TITION_TABLE?) >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> |-- scsi controller (UCLASS_SCSI) >> > > > > > > >>>>>>>> | |-- scsi disk / Physical media (UCLASS_HW_PARTIT= ION_TABLE?) >> > > > > > > >>>>>>>> | |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?) >> > > > > > > >>>>>>>> | | |-- Partition table (UCLASS_PARTITION_TABLE) >> > > > > > > >>>>>>>> | | |-- Software Partition (UCLASS_BLK) >> > > > > > > >>>>>>>> | |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?) >> > > > > > > >>>>>>>> =2E=2E=2E >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> (Here I ignored scsi buses/channels which make thi= ngs more complicated=2E) >> > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> This kind of complex hierarchy doesn't benefit any= body=2E >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> All these levels exist already=2E We simply do not = model them yet in the DM way=2E >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> The device tree depth is the outcome of the udevice= exposing always only a single interface defined by the uclass=2E >> > > > > > > >>>>>>> >> > > > > > > >>>>>>> The UEFI design allows installing multiple protocol= interfaces on a single handle=2E This may result in simpler device trees i= n some cases=2E >> > > > > > > >>>>>> >> > > > > > > >>>>>> Yes, the complexity has to go somewhere=2E With driv= er model I chose to >> > > > > > > >>>>>> have a single interface per uclass, since it is simp= ler to understand, >> > > > > > > >>>>>> no need to request a protocol for a device, etc=2E >> > > > > > > >>>>>> >> > > > > > > >>>>>> Our current setup is similar to this >> > > > > > > >>>>>> >> > > > > > > >>>>>> |-- Controller (UCLASS_MMC) >> > > > > > > >>>>>> | |-- Block device (UCLASS_BLK) - 'usual' HW par= tition >> > > > > > > >>>>>> | |-- Block device (UCLASS_BLK) - e=2Eg=2E for a= different HW partition* >> > > > > > > >>>>>> >> > > > > > > >>>>>> * although I don't think the MMC code actually suppo= rts it - SCSI does though >> > > > > > > >>>>>> >> > > > > > > >>>>>> We want to add devices for the partition table and t= he filesystem, so could do: >> > > > > > > >>>>>> >> > > > > > > >>>>>> |-- Controller (UCLASS_MMC) >> > > > > > > >>>>>> | |-- Block device (UCLASS_BLK) - 'usual' HW par= tition (the whole device) >> > > > > > > >>>>>> | | |-- Partition table (UCLASS_PART) - DOS partiti= on (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=2Eg=2E for a= different HW >> > > > > > > >>>>>> partition (the whole device) >> > > > > > > >>>>>> >> > > > > > > >>>>>> This is similar to Heinrich's, but without the top-l= evel >> > > > > > > >>>>>> UCLASS_HW_PARTITION_TABLE which I am not sure is nec= essary=2E >> > > > > > > >>>>> >> > > > > > > >>>>> Are further MMC hw partitions, multiple SCSI LUNs and= multiple NVME namespaces already treated as separate BLK devices? >> > > > > > > >>>> >> > > > > > > >>>> Yes=2E >> > > > > > > >>>> What I meant to say is that, if we don't need a partit= ion table 'udevice' >> > > > > > > >>>> for hw partitions, we don't need such a device for sw = partitions neither=2E >> > > > > > > >>>> >> > > > > > > >>>> 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 tha= n reading it >> > > > > > > >>> again every time we access a file, we might find it use= ful=2E Open files >> > > > > > > >>> could be children of the FS uclass, perhaps, if we go a= step further >> > > > > > > >>> and create devices for them=2E >> > > > > > > >> >> > > > > > > >> Do you want to invent linux-like mount-point concepts or= procfs? >> > > > > > > >> I remember that you didn't want to have child nodes unde= r BLK devices=2E >> > > > > > > >> I'm getting confused about our goal=2E >> > > > > > > > >> > > > > > > > I think we are all a bit unsure=2E >> > > > > > > > >> > > > > > > > I think BLK devices can have children, sorry if I said th= e wrong thing >> > > > > > > > somewhere along the way=2E For example, a partition would= be under a BLK >> > > > > > > > device, or a FS=2E >> > > > > > > > >> > > > > > > >> What should DM represent in U-Boot world? >> > > > > > > > >> > > > > > > > That is what we are trying to figure out=2E >> > > > > > > > >> > > > > > > > I think the minimum is to have a a way to represent parti= tions (s/w >> > > > > > > > and hw/)=2E As I understand it, that's what we've been di= scussing=2E >> > > > > > > >> > > > > > > The discovery of hardware partitions is specific to the blo= ck device >> > > > > > > controller SCSI/MMC/ATA/NVMe=2E We currently do not provide= any >> > > > > > > manipulation commands to create hardware partitions (e=2Eg= =2E NVMe >> > > > > > > namespaces, SCSI LUNs)=2E This is why extracting a uclass f= or hardware >> > > > > > > partitions does not seem necessary=2E >> > > > > > >> > > > > > I can see the reasoning here=2E It might not stand the test o= f time but >> > > > > > how about we go with it for now? For MMC hardware partition w= e would >> > > > > > just end up with multiple BLK devices, like we do with SCSI L= UNs at >> > > > > > present, which seems like it should work (with some code twea= ks)=2E >> > > > > > >> > > > > > > >> > > > > > > Software partitioning (MBR, GPT, =2E=2E=2E) is independent = of the harboring >> > > > > > > block device=2E >> > > > > > > >> > > > > > > We already have a set of drivers for software partition tab= les in disk/=2E >> > > > > > > Currently the available methods of the drivers are defined = in >> > > > > > > U_BOOT_PART_TYPE referring to struct part_driver=2E >> > > > > > > >> > > > > > > Currently struct part_driver knows only the following metho= ds: >> > > > > > > >> > > > > > > - get_info() >> > > > > > > - print() >> > > > > > > - test() >> > > > > > > >> > > > > > > These drivers should be ome a uclass=2E >> > > > > > > >> > > > > > > gpt=2Ec and mbr=2Ec allow to create and delete partitions= =2E I think we should add >> > > > > > > >> > > > > > > - create_partition() >> > > > > > > - delete_partition() >> > > > > > > >> > > > > > > to the uclass methods=2E >> > > > > > >> > > > > > That sounds good to me, although since it is a partition ucla= ss, we >> > > > > > can just use create() and delete()=2E >> > > > > >> > > > > I don't know why we need a "partition table" device in the midd= le >> > > > > of DM hierarchy=2E >> > > > > I believe that it simply makes the view of DM tree complicated >> > > > > without any explicit benefit=2E >> > > > >> > > > Well we clearly have an API here=2E 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 pare= nt >> > > > (unless they are whole-device filesystems), which makes sense >> > > > >> > > > So that's why I like the idea=2E >> > > > >> > > > Other than the extra complexity, is there anything else wrong wit= h it? >> > > >> > > - First of all, a partition table doesn't look like a 'device' at a= ll=2E >> > > - Second, a partition table is just static data for block devices= =2E >> > > 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' whic= h >> > > I will introduce in the next version=2E >> > > >> > > -Takahiro Akashi >> > > >> > >> > I don't know how this affect the code, but I agree with Akashi-san >> > here=2E It's indeed useful to keep the partition table stored >> > somewhere, but I think not showing them as part of the device tree i= s >> > more intuitive=2E >> >> Well I think I'm easy either way=2E I just thought that Heinrich made a >> good case for having a partition uclass=2E >> >> But as Takahiro says, we can use a tag to attach the partition table >> to the device=2E But it should be attached to the device's children (th= e >> 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=2E > Without uclass you cannot bring the partition table drivers into th driver= model=2E No clue what a tag should be in the driver model=2E Best regards Heinrich >Regards, >Simon