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 E32E4C433EF for ; Mon, 1 Nov 2021 02:14: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 1D5B860EBC for ; Mon, 1 Nov 2021 02:14:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D5B860EBC 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 E963A834A4; Mon, 1 Nov 2021 03:14: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=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="VDa41FZi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3035483576; Mon, 1 Nov 2021 03:14:31 +0100 (CET) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 8421B815A8 for ; Mon, 1 Nov 2021 03:14:26 +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-x929.google.com with SMTP id v3so29191833uam.10 for ; Sun, 31 Oct 2021 19:14:26 -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=/cBmDF7CluIWlSGLTC8Po4OVbvXXmZkAXSGqQtX7bVk=; b=VDa41FZi9QJqTryJ428YeMjHebzhFUOXtxwVVPEtQk6461mv9R1DqdF5oT0g3aQYCt LioIjUjcYgUMSvjXLa4UKPik7tSraKztD/q6rV30Ey5tpYcRs1klPfeZ0rymLA/6BEik 7aUVj4SSvH1Kq2uJGXtDASvAHW02IRhbWN6MI= 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=/cBmDF7CluIWlSGLTC8Po4OVbvXXmZkAXSGqQtX7bVk=; b=6/Tf8Evftlu0b4GS6q+Dyn+JrxJMEVlea6kjcEnVLT8XKLFJHl6GxfDQWViKdfwyvp QhFZ/otYgabdfkpIF3Ewg4VD4K3IIHE+splWaTG+9Xz0jn//Hk28g6r7M8kiDoGC2Lwc 7EslgDxN8zACqFtxQEYwBtuog1GTSrPhF20MAM8db2k2Oyb4ALL5wM3eP6UuTQv9dRRN QUGz3pYnFYgSq1+2Go5nWmVpTakEIqUETZo2ND/ZSN+VZEKEHCJVcSQBhl/McN+Avyzm 2wXsKGsCEWRnVkWlygFcArEssMPG1kgRt2flcBQee8Hwyzc2dF1nZs0mnKuaKd+5Qe6I Scig== X-Gm-Message-State: AOAM533VThsgnmp4AYzN+KmyB5KSKdbPCmoiEbcMO8iwziVUVNnSGs0r 8u0EEsgkKgnSC3h6mp6HlpbuFCUstB601cYBnSGLTg== X-Google-Smtp-Source: ABdhPJzVTs6xxWY9m08M1KYjy0emU+Tzevl41TZ9uo78GMBwBku/140NNC1E3O1bkZq7TZaNKtxbshZIy5SuOpDfyxg= X-Received: by 2002:a67:3087:: with SMTP id w129mr25207130vsw.15.1635732864727; Sun, 31 Oct 2021 19:14:24 -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> In-Reply-To: <20211101015155.GC25300@laputa> From: Simon Glass Date: Sun, 31 Oct 2021 20:14:13 -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 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 w= rote: > > > > >> >> > > > > >> >> > > > > >> >> > 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= 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? Wh= at would > > > > >> >> > the picture look like the, and would it get us closer to ag= reement? > > > > >> >> > > > > >> >> 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 UCL= ASS and is > > > > >> >> accessed through this UCLASS's interface. > > > > >> > > > > > >> >Please be careful about "accessed through" which is a quite con= fusing > > > > >> >expression. I don't always agree with this view. > > > > >> > > > > > >> >> A hardware partition is an object that exposes only a single = interface > > > > >> >> for block IO. > > > > >> >> > > > > >> >> A software partition is an object that may expose two interfa= ces: 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 devi= ces > > > > >> >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-Bo= ot'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 ex= tra interfaces. > > > > >> > > > > > >> >> We have the following logical levels: > > > > >> >> > > > > >> >> Controller | Block device | Software Partition| File sys= tem > > > > >> >> ----------------+--------------+-------------------+---------= --- > > > > >> >> NVMe Drive | Namespace | Partition 1..n | FAT, EXT= 4 > > > > >> >> 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= 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 inde= pendent of the block device type we should use separate uclasses and udevic= es. > > > > >> > > > > >> >I also remember that you claimed that not all efi objects(handl= es and > > > > >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresp= onding > > > > >> >U-Boot counterparts in our 2019 discussion. > > > > >> > > > > > >> >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_T= ABLE, > > > > >> >which should support other type of hw partitions as well? > > > > >> > > > > >> How hardware partitions, LUNs, ATA drives are enumerated is spec= ific to the type of controller while the type of software partition table = is 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 comp= licated.) > > > > >> > > > > > >> >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 alw= ays only a single interface defined by the uclass. > > > > >> > > > > >> The UEFI design allows installing multiple protocol interfaces o= n 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 '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. 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 s= oftware > > > > >> >> partition does the same. It is created by the partition table= driver as > > > > >> >> child of the partition table udevice. > > > > >> >> > > > > >> >> In this model an eMMC device will not be a UCLASS_BLK device = because it > > > > >> >> does not expose block IO. It is the hardware partition that e= xposes this > > > > >> >> interface. > > > > >> >> > > > > >> >> The suggested model will allow a clean description of nested = partition > > > > >> >> tables. > > > > >> >> > > > > >> >> In the UEFI world the software partition and its file system = must be > > > > >> >> mapped to a single handle with device path node type HD(). Fo= r the > > > > >> >> parent block device we may create a child handle with partiti= on number 0 > > > > >> >> (HD(0)). For the partition table we will not create a handle. > > > > >> >> > > > > >> >> Best regards > > > > >> >> > > > > >> >> Heinrich