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 27426C433EF for ; Tue, 2 Nov 2021 07:38:35 +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 537BF60EB9 for ; Tue, 2 Nov 2021 07:38:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 537BF60EB9 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 194FC82E48; Tue, 2 Nov 2021 08:38:32 +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="VhNscC3l"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A02A582EEC; Tue, 2 Nov 2021 08:38:30 +0100 (CET) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9D1C382051 for ; Tue, 2 Nov 2021 08:38:26 +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=1635838704; bh=SqK2zm+6j59sU2BF5QYpvP/kvt+Ovme7YdUtgCurp2A=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=VhNscC3lzA3pvJPuzTiP4DUvjvy43oc5qFj7CaxLaGGJrAbBUbey9uIx1AbOjlzQp RieZF+KCgNN6dw1Bc/4NRhFvcDq6Y/PPJ0Lyd6CO2K4QitZmjO7umDTNqWoCs4ca6R uZn++7jdMKL+NB2yOyRl/f1e45OeX9Gx3qglfgFw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.35] ([88.152.144.157]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N49hB-1mZ2wr2RZB-0103Yq; Tue, 02 Nov 2021 08:38:24 +0100 Message-ID: <3b96557b-ff89-19e0-e250-200dc19eb93d@gmx.de> Date: Tue, 2 Nov 2021 08:38:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION Content-Language: en-US To: Simon Glass , AKASHI Takahiro , Tom Rini , U-Boot Mailing List , Ilias Apalodimas , Alex Graf References: <20211028085217.GA98815@laputa> <111f3160-3b5e-302e-c0ca-86c66093207e@gmx.de> <20211029061556.GD33977@laputa> <20211101003600.GB25300@laputa> <20211101015155.GC25300@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:kySlmOcAdgyTYpvNG9rB6JBENg0HhudL4qku5KrMg8bfsvMtKf+ fBCMAhoCxqfuhF1oFt8icyYsVpLNp5L66ppwzIgXQXCbzi+DQyQhTws7VC4unKkx1W37eS4 0mnlfThSSrTasXeQGHH6C7tTq7658b1Rv/nDvYyVh/yxhOeoVqrZTNfLSuvmxs0bbV/mFDI vV8tcnx3qpDmUg5AtZ1SQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:JLd7Md12vfg=:8Qwgru4GJrdRPzEgN3KBNt 5RrTTINjbFQytTDYxE5sYutZZMK7m5j+PDqS9o9doVvU3DTlEe9yUYlr0sJ5nxbtanXVXR1jZ Ps0LeLBp8aNvBfZLTMFAOLO0eQVNXy1C9gyqOcjVXZ/rp9aUTTzhPfMfOtT2LDeO46NLu4qXM hOcFu/QK7GockoS2FUFbPDezdYuAtCoZnzFA7eorir7GxgNep08+5ilvJ6SolQHPI8U7Q6wvd tRrcEUQp+mEQXRN02CSPw23XLoMGlLGN+e8GSR6761GksTMqOUCRJ9TdvBF5lnlGD357zmQER ZcpiLqRUrNycyybCrVFX7udSuQbo59+uZwMKpUUfBORQUzs/O4pEWY+APyusM2VNPKqfxuSO1 TNHngaMBFvva/X++yFaI9fyBPiqEg7co8uWmr2IfVYZBmXOSLPyZl9GHcKpqKGIgSbF3UgnJi cydPbvjXM6Dq/UryZSmfAJF/Q5i10lMeOZrbZvfaoNe8pPGbIlp6ixOxAsiQFmjz4ffiCq47J H1qirVp6iU+4NetUl1wBNSSJJ40uyYi3szXeS29Lt2dDE2ye8Y+zr+SyNbHpqs28EPrs+U6+Y 5nrWqUSt/Qz6KqnngeiJVSGLTZJufb799IfDdJWGilkoZwINcSgkWoxKXAmOtP+I6dwMEYvZr r6LJaQ34MF9OzWsSSg0uQPVih7/AMGaCmt3ECZLotIhGj+7Tu5ngfK5/C0OGL23KsuTA8kFBW Chz9VSjem5fPzJqOZ9bz4hMORqct4igy9RYHuB9Ttk1FiegG9ANe6oMcHcXrHX8hjSCO3vXMg vVCiJbPCO470NqwmiZnFSpoWlML97NzUIkONKTU/G/mGiVqi/yQuJEp2nonUPxp0d/nb/LlOP Bg6biqooZYzIl+1oBy8so9leDqZmmSF67/5eRbXpYvZK2R6q5Bsl7fZIWhOwb1/qRBZtRWI2x xKgl7flX1RdH89RwIp9QUTFNLP0DDUrv/TQ6AD7E0TTWFi74BlRN6gyfmd/yB+jhDb+DfrwHt oqdcLgyzDYZ8rXAtrsKnM9WWyXVi00vgTHBYKrZBQSwch/v9kpnxvjtP4yXHh31AdSBlMieEf mPyCrm5FqMEAfE= 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 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 wro= te: >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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 you= r >>>>>>>>>> argument. >>>>>>>>>> >>>>>>>>>> If we use UCLASS_PART, for example, can we have that refer to b= oth s/w >>>>>>>>>> and h/w partitions, as Herinch seems to allude to below? What w= ould >>>>>>>>>> the picture look like the, and would it get us closer to agreem= ent? >>>>>>>>> >>>>>>>>> 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 UCLASS= and is >>>>>>>>> accessed through this UCLASS's interface. >>>>>>>> >>>>>>>> Please be careful about "accessed through" which is a quite confu= sing >>>>>>>> expression. I don't always agree with this view. >>>>>>>> >>>>>>>>> A hardware partition is an object that exposes only a single int= erface >>>>>>>>> for block IO. >>>>>>>>> >>>>>>>>> A software partition is an object that may expose 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 system >>>>>>>> if you want. >>>>>>>> It's a matter of usage. >>>>>>>> >>>>>>>> I remember that we had some discussion about whether block device= s >>>>>>>> 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 ha= ndle 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-Boo= t has >>>>>>>>> overcome this limitation by creating child devices for 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 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 f= uture 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 inde= pendent of the block device type we should use separate uclasses and udevi= ces. >>>>>>> >>>>>>>> I also remember that you claimed that not all efi objects(handles= and >>>>>>>> protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have correspon= ding >>>>>>>> U-Boot counterparts in our 2019 discussion. >>>>>>>> >>>>>>>> If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TAB= LE, >>>>>>>> which should support other type of hw partitions as well? >>>>>>> >>>>>>> How hardware partitions, LUNs, ATA drives are enumerated is specif= ic 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 compli= cated.) >>>>>>>> >>>>>>>> This kind of complex hierarchy doesn't benefit anybody. >>>>>>> >>>>>>> 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 exposing alway= s 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 understa= nd, >>>>>> 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 parti= tion* >>>>>> >>>>>> * although I don't think the MMC code actually supports it - SCSI d= oes 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 who= le 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 'udev= ice' >>>> for hw partitions, we don't need such a device for sw partitions neit= her. >>>> >>>> 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 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 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. 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 a= dd - create_partition() - delete_partition() to the uclass methods. 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. Best regards Heinrich > > Regards, > Simon > >> >> >>> 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 soft= ware >>>>>>>>> partition does the same. It is created by the partition table dr= iver as >>>>>>>>> child of the partition table udevice. >>>>>>>>> >>>>>>>>> In this model an eMMC device will not be a UCLASS_BLK device bec= ause it >>>>>>>>> does not expose block IO. It is the hardware partition that expo= ses this >>>>>>>>> interface. >>>>>>>>> >>>>>>>>> The suggested model will allow a clean description of nested par= tition >>>>>>>>> tables. >>>>>>>>> >>>>>>>>> In the UEFI world the software partition and its file system mus= t be >>>>>>>>> mapped to a single handle with device path node type HD(). For t= he >>>>>>>>> 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