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 3330FC433F5 for ; Sat, 13 Nov 2021 21:32:47 +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 A650760E90 for ; Sat, 13 Nov 2021 21:32:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A650760E90 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 3A8F8832DB; Sat, 13 Nov 2021 22:32:45 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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; unprotected) header.d=chromium.org header.i=@chromium.org header.b="EzXfDqHI"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6E5CB832FB; Sat, 13 Nov 2021 22:32:39 +0100 (CET) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2B735832DB for ; Sat, 13 Nov 2021 22:32:33 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ua1-x936.google.com with SMTP id p2so26282205uad.11 for ; Sat, 13 Nov 2021 13:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PZ9UHMKCFnGJ2cnOaY1LNEJnCTfNUrRZcno8d7aZ/Zo=; b=EzXfDqHIYAQNSUAxEZY4oVKQUYX84g5M58SH98iZ9uWy7eIkeNYg8YGH83DX0iK62l UyDCiGgMmL3Ah6/u369zXmMXLbzh33HWsTXgaun2x4cEvuBUFg0HB+6CppC6pir1eAp0 R1EdycTdFhf0v5jJWhG28SGLQAIQcjs/pllic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PZ9UHMKCFnGJ2cnOaY1LNEJnCTfNUrRZcno8d7aZ/Zo=; b=zHtv/PM8yoG+RgubF3y5BsscX1zc/sb4sumSIzboQNISsWEdoLP8LpkbICbT3U4ROX kAz757Yfu5/Evxu605niBzUkBFXiNK1ezAE/oVV23xccDVL+/81BBBn4yjILOCO2fYrh 9HDGfFfYr8o4xHZW5rtcxiTK0El3fELOQaAJ5vRz8Z5uOWrWn81z+U/xrKM80rAmPB+M gR0X8cZCrPiNNyii5fabGs+sV8nBTeMCg9WGMf6wR6enlP5mmy+K35DZlgJqWmJXYKFF HSb3sWOQmarsljmDMlKs+o4sRZvWU/7169uCX+bMmwUW/O/16LNmFKBuA3O7QEYQwOkv 6efQ== X-Gm-Message-State: AOAM532BMg1+tm3Hy2lwX2IDJ71JFP+TKSWYrcJC3oI3JVb3lQSN0Luq vwO5r+Z+Cxow7sctMPylNo1gEZbCTBIdfG7D4gl0Xg== X-Google-Smtp-Source: ABdhPJyVfLF4V9mheTy24+CRmdqfs1ZVxgRomrSguedeIQXAiP+/vKwnY5HRZ1P1gSaX9ErsB7+Cp7hKeoqH5+MH1ho= X-Received: by 2002:ab0:4465:: with SMTP id m92mr38356467uam.47.1636839151607; Sat, 13 Nov 2021 13:32:31 -0800 (PST) MIME-Version: 1.0 References: <20211101003600.GB25300@laputa> <20211101015155.GC25300@laputa> <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> <20211105024929.GD27316@laputa> <20211108044637.GD16401@laputa> In-Reply-To: From: Simon Glass Date: Sat, 13 Nov 2021 14:32:20 -0700 Message-ID: Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION To: Heinrich Schuchardt Cc: Ilias Apalodimas , AKASHI Takahiro , Tom Rini , U-Boot Mailing List , Alex Graf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Hi Heinrich, On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt wrot= e: > > 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 w= rote: > >> > > > > > > >>> Hi Takahiro, > >> > > > > > > >>> > >> > > > > > > >>> On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro > >> > > > > > > >>> wrote: > >> > > > > > > >>>> > >> > > > > > > >>>> On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Sc= huchardt wrote: > >> > > > > > > >>>>> > >> > > > > > > >>>>> > >> > > > > > > >>>>> Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glas= s : > >> > > > > > > >>>>>> Hi, > >> > > > > > > >>>>>> > >> > > > > > > >>>>>> On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt <= xypron.glpk@gmx.de> wrote: > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI T= akahiro : > >> > > > > > > >>>>>>>> On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinric= h Schuchardt wrote: > >> > > > > > > >>>>>>>>> > >> > > > > > > >>>>>>>>> > >> > > > > > > >>>>>>>>>> I agree with Heinrich that we are better to lea= ve 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 sa= me interface. > >> > > > > > > >>>>>>>>> A UDEVICE is a logical device that belongs to ex= actly 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 o= nly a single interface > >> > > > > > > >>>>>>>>> for block IO. > >> > > > > > > >>>>>>>>> > >> > > > > > > >>>>>>>>> A software partition is an object that may expos= e 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 sy= stem > >> > > > > > > >>>>>>>> if you want. > >> > > > > > > >>>>>>>> It's a matter of usage. > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> I remember that we had some discussion about whet= her block devices > >> > > > > > > >>>>>>>> on UEFI system should always have a (sw) partitio= n 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 w= ish. 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 devic= es for the extra interfaces. > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>>> We have the following logical levels: > >> > > > > > > >>>>>>>>> > >> > > > > > > >>>>>>>>> Controller | Block device | Software Partit= ion| 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 de= vice, without a > >> > > > > > > >>>>>> partition table. This is supported in U-Boot and Li= nux. > >> > > > > > > >>>>>> > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> 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 uclas= ses and udevices. > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>>> I also remember that you claimed that not all efi= objects(handles and > >> > > > > > > >>>>>>>> protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need t= o 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 enum= erated is specific to the type of controller while the type of software par= tition table is independent of the block device. > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> |-- eMMC controller (UCLASS_MMC) > >> > > > > > > >>>>>>>> | |-- eMMC device1 / Physical media (UCLASS_HW_PA= RTITION_TABLE?) > >> > > > > > > >>>>>>>> | |-- Block device / HW Partition:user data (UC= LASS_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_PA= RTITION_TABLE?) > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> |-- scsi controller (UCLASS_SCSI) > >> > > > > > > >>>>>>>> | |-- scsi disk / Physical media (UCLASS_HW_PARTI= TION_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 th= ings more complicated.) > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> This kind of complex hierarchy doesn't benefit an= ybody. > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> All these levels exist already. We simply do not m= odel them yet in the DM way. > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> The device tree depth is the outcome of the udevic= e exposing always only a single interface defined by the uclass. > >> > > > > > > >>>>>>> > >> > > > > > > >>>>>>> The UEFI design allows installing multiple protoco= l interfaces on a single handle. This may result in simpler device trees in= some cases. > >> > > > > > > >>>>>> > >> > > > > > > >>>>>> Yes, the complexity has to go somewhere. With drive= r model I chose to > >> > > > > > > >>>>>> have a single interface per uclass, since it is sim= pler 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 pa= rtition > >> > > > > > > >>>>>> | |-- Block device (UCLASS_BLK) - e.g. for a di= fferent HW partition* > >> > > > > > > >>>>>> > >> > > > > > > >>>>>> * although I don't think the MMC code actually supp= orts 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 pa= rtition (the whole device) > >> > > > > > > >>>>>> | | |-- Partition table (UCLASS_PART) - DOS partit= ion (or EFI) > >> > > > > > > >>>>>> | | | |-- Block device (UCLASS_BLK) - partition 1 > >> > > > > > > >>>>>> | | | | |-- Filesystem (UCLASS_FS) - DOS filesystem > >> > > > > > > >>>>>> | | | |-- Block device (UCLASS_BLK) - partition 2 > >> > > > > > > >>>>>> | | | | |-- Filesystem (UCLASS_FS) - ext5 filesyste= m > >> > > > > > > >>>>>> | |-- Block device (UCLASS_BLK) - e.g. for a di= fferent 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 ne= cessary. > >> > > > > > > >>>>> > >> > > > > > > >>>>> Are further MMC hw partitions, multiple SCSI LUNs an= d multiple NVME namespaces already treated as separate BLK devices? > >> > > > > > > >>>> > >> > > > > > > >>>> Yes. > >> > > > > > > >>>> What I meant to say is that, if we don't need a parti= tion 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 th= an reading it > >> > > > > > > >>> again every time we access a file, we might find it us= eful. 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 o= r procfs? > >> > > > > > > >> I remember that you didn't want to have child nodes und= er 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 t= he 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 part= itions (s/w > >> > > > > > > > and hw/). As I understand it, that's what we've been dis= cussing. > >> > > > > > > > >> > > > > > > The discovery of hardware partitions is specific to the bl= ock 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 fo= r 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 twe= aks). > >> > > > > > > >> > > > > > > > >> > > > > > > Software partitioning (MBR, GPT, ...) is independent of th= e harboring > >> > > > > > > block device. > >> > > > > > > > >> > > > > > > We already have a set of drivers for software partition ta= bles 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 meth= ods: > >> > > > > > > > >> > > > > > > - get_info() > >> > > > > > > - print() > >> > > > > > > - test() > >> > > > > > > > >> > > > > > > These drivers should be ome a uclass. > >> > > > > > > > >> > > > > > > gpt.c and mbr.c allow to create and delete partitions. I t= hink we should add > >> > > > > > > > >> > > > > > > - create_partition() > >> > > > > > > - delete_partition() > >> > > > > > > > >> > > > > > > to the uclass methods. > >> > > > > > > >> > > > > > That sounds good to me, although since it is a partition ucl= ass, we > >> > > > > > can just use create() and delete(). > >> > > > > > >> > > > > I don't know why we need a "partition table" device in the mid= dle > >> > > > > 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' whi= ch > >> > > 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 drive= r model. > > 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. Regards, Simon