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 55976C433F5 for ; Fri, 5 Nov 2021 02:06:15 +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 D666060E8C for ; Fri, 5 Nov 2021 02:06:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D666060E8C 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 8A59D8374C; Fri, 5 Nov 2021 03:04:47 +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="CDBEkjEo"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D877983714; Fri, 5 Nov 2021 03:03:45 +0100 (CET) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D7E318372C for ; Fri, 5 Nov 2021 03:03:17 +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-ot1-x331.google.com with SMTP id g25-20020a9d5f99000000b0055af3d227e8so6551069oti.11 for ; Thu, 04 Nov 2021 19:03:17 -0700 (PDT) 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=yJl1sTSIE8hYG4TZADuuzer/P733mvL2AfpJayjjrN0=; b=CDBEkjEo5kr849yEzsW5mkPgr9mCZaWOI7UX06UTS7OrsZfO2QaTitOcfIf5ucF4A/ 8c+SmHFMzRg8ia/2gsVtssLM2v8Oq3BlS0FQKMGOjeFxHOwtsDSMVSUskL+8CIW3HDEa YKGy41qBvXI8yyTIRF7DqkJD49zGvY605Yggw= 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=yJl1sTSIE8hYG4TZADuuzer/P733mvL2AfpJayjjrN0=; b=h7hh78wOpqudYapnRpj/7BKEGL0Qmo+T/X3jxltmdywc1yym0LuLDBBX/zEjJA2lMo G2eUo4og+e51GbSpKyEAt7mJAhFZAdl7sCj2c4DV/MdORiPo4Rw4X2xaV7gNdqr+md/Z IBxFqYywc2XiZYY0BApOFm9TJD4EU7RBvbAwy+ta99mw+2fYj2IbeMLQ8DqCkszHsLKY 7xqq3oQiJPMzI9LFm5dsKwg/KAJNRMEZ7b7E474/f61KtSSfFlDzibgvQgUR9e+BEV0O PvONlVLo0cNuZLg7W525Xhu//ebd4biJ1lQnRvYV6IXzA4za/piKrhC4JgNdE79cxn9B 2qqw== X-Gm-Message-State: AOAM532cnys3QjwGfyRV/6s9S2K1ajxSSwzph0FApuQa3uLFmvchigmz YE/1VjCXqRQl9SXBRziRgo2iWrEascj5+UknbwnNaA== X-Google-Smtp-Source: ABdhPJyAp1I+yEkUCJ1E7Tii9C+MHKVH3UMRRf1RSurUV7clop7CMkZlQt4F8EZwv5UG1ui3USKjZ4+pfcgoB/sv+20= X-Received: by 2002:a9d:37e3:: with SMTP id x90mr35577224otb.11.1636077795727; Thu, 04 Nov 2021 19:03:15 -0700 (PDT) MIME-Version: 1.0 References: <20211028085217.GA98815@laputa> <111f3160-3b5e-302e-c0ca-86c66093207e@gmx.de> <20211029061556.GD33977@laputa> <20211101003600.GB25300@laputa> <20211101015155.GC25300@laputa> <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> In-Reply-To: <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> From: Simon Glass Date: Thu, 4 Nov 2021 20:02:05 -0600 Message-ID: Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION To: Heinrich Schuchardt Cc: AKASHI Takahiro , Tom Rini , U-Boot Mailing List , Ilias Apalodimas , 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.34 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, 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 Schuchardt 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 Takahiro : > >>>>>>>> On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wr= ote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> 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 yo= ur > >>>>>>>>>> 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 agree= ment? > >>>>>>>>> > >>>>>>>>> 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 UCLAS= S and is > >>>>>>>>> accessed through this UCLASS's interface. > >>>>>>>> > >>>>>>>> Please be careful about "accessed through" which is a quite conf= using > >>>>>>>> expression. I don't always agree with this view. > >>>>>>>> > >>>>>>>>> A hardware partition is an object that exposes only a single in= terface > >>>>>>>>> for block IO. > >>>>>>>>> > >>>>>>>>> A software partition is an object that may expose two interface= s: 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 devic= es > >>>>>>>> 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 h= andle 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-Bo= ot has > >>>>>>>>> overcome this limitation by creating child devices for the extr= a interfaces. > >>>>>>>> > >>>>>>>>> We have the following logical levels: > >>>>>>>>> > >>>>>>>>> Controller | Block device | Software Partition| File syste= m > >>>>>>>>> ----------------+--------------+-------------------+-----------= - > >>>>>>>>> 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 D= M 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 d= rivers have a common interface. As the partition table type is mostly indep= endent of the block device type we should use separate uclasses and udevice= s. > >>>>>>> > >>>>>>>> I also remember that you claimed that not all efi objects(handle= s and > >>>>>>>> protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have correspo= nding > >>>>>>>> U-Boot counterparts in our 2019 discussion. > >>>>>>>> > >>>>>>>> If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TA= BLE, > >>>>>>>> which should support other type of hw partitions as well? > >>>>>>> > >>>>>>> How hardware partitions, LUNs, ATA drives are enumerated is speci= fic to the type of controller while the type of software partition table i= s 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 compl= icated.) > >>>>>>>> > >>>>>>>> This kind of complex hierarchy doesn't benefit anybody. > >>>>>>> > >>>>>>> All these levels exist already. We simply do not model them yet i= n the DM way. > >>>>>>> > >>>>>>> The device tree depth is the outcome of the udevice exposing alwa= ys 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 underst= and, > >>>>>> 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 part= ition* > >>>>>> > >>>>>> * 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 wh= ole 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 'ude= vice' > >>>> for hw partitions, we don't need such a device for sw partitions nei= ther. > >>>> > >>>> 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 file= s > >>> 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(). > > The partitions handled by cmd/mtdparts.c, cmd/nand.c are also software > partitions. The difference to MBR, GPT is that the partition table is > held in memory and not on disk. These partitions could be modeled in the > same uclass. For future work! Regards, SImon > >>> > >>>>>> > >>>>>> It is compatible with what we have now and we could enable/disable= the > >>>>>> extra devices with a Kconfig. > >>>>>> > >>>>>> Regards, > >>>>>> Simon > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> > >>>>>>>>> UCLASS_PARTITION_TABLE would be for the drivers in disk/. > >>>>>>>>> UCLASS_FS would be for the drivers in fs/. > >>>>>>>>> UCLASS_BLK will be for any objects exposing raw block IO. A sof= tware > >>>>>>>>> partition does the same. It is created by the partition table d= river as > >>>>>>>>> child of the partition table udevice. > >>>>>>>>> > >>>>>>>>> In this model an eMMC device will not be a UCLASS_BLK device be= cause it > >>>>>>>>> does not expose block IO. It is the hardware partition that exp= oses this > >>>>>>>>> interface. > >>>>>>>>> > >>>>>>>>> The suggested model will allow a clean description of nested pa= rtition > >>>>>>>>> tables. > >>>>>>>>> > >>>>>>>>> In the UEFI world the software partition and its file system mu= st be > >>>>>>>>> mapped to a single handle with device path node type HD(). For = the > >>>>>>>>> parent block device we may create a child handle with partition= number 0 > >>>>>>>>> (HD(0)). For the partition table we will not create a handle. > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> > >>>>>>>>> Heinrich