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 428E6C433F5 for ; Fri, 5 Nov 2021 16:13:37 +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 BE50B6023B for ; Fri, 5 Nov 2021 16:13:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BE50B6023B 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 A3A3083735; Fri, 5 Nov 2021 17:12:56 +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="NxCNjkqh"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3D63E8371F; Fri, 5 Nov 2021 17:12:43 +0100 (CET) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 1CDFF8371F for ; Fri, 5 Nov 2021 17:12:32 +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-x92d.google.com with SMTP id e2so18008564uax.7 for ; Fri, 05 Nov 2021 09:12:32 -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 :content-transfer-encoding; bh=N3wowTdKd9PmimqHcgbCUXsE28ouDEpklV/Syq2zDsw=; b=NxCNjkqh5LHB3uuX/idMv39YiIgJTNiQd+1CHutWfwJ5GlFWkTSfDskKIdF1o5ijkq Aco5yruSK9y/R0Qdmbn5V/TY1GsLc0b6qewmc4KY9esZU+EhsLnfkiADDcu91rqrbpRO kRmzptNRA79IWXujTKw9LMZXWuUIin3HFYoQ0= 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:content-transfer-encoding; bh=N3wowTdKd9PmimqHcgbCUXsE28ouDEpklV/Syq2zDsw=; b=8LaLoFmZRaOew/dZRSHb+bj16QfMD+d/PNd2/t9MuarTvoNWhTK+jxXCYem/kauc0S XZWJLRCCpktbBBTTjlu8yKCabQ/6jaTFTgBUv8USGTaFYyiyq1V78oFp/8X4EIunic+I fYCjm5+G1/WzG6136nFYcJhCFMt7oTen4mxBDc5wP0BZ7BmGW+/sPYYhED9nCicyKw70 2ZkQCS+f++MagnR1oj+rn04zlV7Z+OQ9Ny9M/N9E3/aTzxMZZwGEIgdso+5RXOHBvLpV SEOpdEqG+FTu5bYtGf4urOoTDaWF7INl7ueL8GeGwf7zrg8zU1XWLKT47zp+r+E8jkv5 uSkQ== X-Gm-Message-State: AOAM533kYl53WyMmhN8j0q6iFIZJHDB5uKXa7PRjMvqEc/+5tpvzl+ck iWuufAYGlokIXKghHqHQRQSGpvbUsYhRWUNSjDB/JQ== X-Google-Smtp-Source: ABdhPJzZ4Mf0lENrGWrJewD6bNCQ+MNDJiarVXbn+7kBw4/n9KTHSJs7X2vnV6BtbZU5NZkGX7A1K7uRBZHnS8Y3DnU= X-Received: by 2002:ab0:14a7:: with SMTP id d36mr67071104uae.96.1636128750281; Fri, 05 Nov 2021 09:12:30 -0700 (PDT) MIME-Version: 1.0 References: <20211029061556.GD33977@laputa> <20211101003600.GB25300@laputa> <20211101015155.GC25300@laputa> <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> <20211105024929.GD27316@laputa> In-Reply-To: <20211105024929.GD27316@laputa> From: Simon Glass Date: Fri, 5 Nov 2021 10:12:16 -0600 Message-ID: Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION To: AKASHI Takahiro , Simon Glass , Heinrich Schuchardt , 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 Takahiro, On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro w= rote: > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote: > > Hi, > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt w= rote: > > > > > > > > > > > > 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 wr= ote: > > > >>>>> > > > >>>>> > > > >>>>> 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 Schuchard= t wrote: > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>>> I agree with Heinrich that we are better to leave BLK as i= t is, both > > > >>>>>>>>>> in name and meaning. I think maybe I am missing the gist o= f 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? W= hat would > > > >>>>>>>>>> the picture look like the, and would it get us closer to a= greement? > > > >>>>>>>>> > > > >>>>>>>>> In the driver model: > > > >>>>>>>>> > > > >>>>>>>>> A UCLASS is a class of drivers that share the same interfac= e. > > > >>>>>>>>> A UDEVICE is a logical device that belongs to exactly one U= CLASS 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 singl= e interface > > > >>>>>>>>> for block IO. > > > >>>>>>>>> > > > >>>>>>>>> A software partition is an object that may expose two inter= faces: 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 d= evices > > > >>>>>>>> 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 s= ystem > > > >>>>>>>>> ----------------+--------------+-------------------+-------= ----- > > > >>>>>>>>> NVMe Drive | Namespace | Partition 1..n | FAT, E= XT4 > > > >>>>>>>>> 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, witho= ut 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 the= se drivers have a common interface. As the partition table type is mostly i= ndependent of the block device type we should use separate uclasses and ude= vices. > > > >>>>>>> > > > >>>>>>>> I also remember that you claimed that not all efi objects(ha= ndles and > > > >>>>>>>> protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corr= esponding > > > >>>>>>>> U-Boot counterparts in our 2019 discussion. > > > >>>>>>>> > > > >>>>>>>> If we *need* PARTITION_TALBLE, why don't we have HW_PARTITIO= N_TABLE, > > > >>>>>>>> which should support other type of hw partitions as well? > > > >>>>>>> > > > >>>>>>> How hardware partitions, LUNs, ATA drives are enumerated is s= pecific to the type of controller while the type of software partition tabl= e is independent of the block device. > > > >>>>>>> > > > >>>>>>>> > > > >>>>>>>> |-- eMMC controller (UCLASS_MMC) > > > >>>>>>>> | |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TAB= LE?) > > > >>>>>>>> | |-- 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_TAB= LE?) > > > >>>>>>>> > > > >>>>>>>> |-- 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 c= omplicated.) > > > >>>>>>>> > > > >>>>>>>> This kind of complex hierarchy doesn't benefit anybody. > > > >>>>>>> > > > >>>>>>> All these levels exist already. We simply do not model them y= et 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 interface= s 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 c= hose to > > > >>>>>> have a single interface per uclass, since it is simpler to und= erstand, > > > >>>>>> 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 - S= CSI does though > > > >>>>>> > > > >>>>>> We want to add devices for the partition table and the filesys= tem, so could do: > > > >>>>>> > > > >>>>>> |-- Controller (UCLASS_MMC) > > > >>>>>> | |-- Block device (UCLASS_BLK) - 'usual' HW partition (th= e 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 'o= pen' > > > >>> 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 furt= her > > > >>> 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 devi= ces. > > > >> 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 th= ing > > > > 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 dis= k/. > > > 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 sho= uld 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? Regards, Simon > > -Takahiro Akashi > > > > > > > > The partitions handled by cmd/mtdparts.c, cmd/nand.c are also softwar= e > > > 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/dis= able 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= software > > > >>>>>>>>> partition does the same. It is created by the partition tab= le driver as > > > >>>>>>>>> child of the partition table udevice. > > > >>>>>>>>> > > > >>>>>>>>> In this model an eMMC device will not be a UCLASS_BLK devic= e because it > > > >>>>>>>>> does not expose block IO. It is the hardware partition that= exposes this > > > >>>>>>>>> interface. > > > >>>>>>>>> > > > >>>>>>>>> The suggested model will allow a clean description of neste= d partition > > > >>>>>>>>> tables. > > > >>>>>>>>> > > > >>>>>>>>> In the UEFI world the software partition and its file syste= m must be > > > >>>>>>>>> mapped to a single handle with device path node type HD(). = For the > > > >>>>>>>>> parent block device we may create a child handle with parti= tion number 0 > > > >>>>>>>>> (HD(0)). For the partition table we will not create a handl= e. > > > >>>>>>>>> > > > >>>>>>>>> Best regards > > > >>>>>>>>> > > > >>>>>>>>> Heinrich