From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Tom Rini <trini@konsulko.com>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Alex Graf <agraf@csgraf.de>
Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
Date: Mon, 1 Nov 2021 10:51:55 +0900 [thread overview]
Message-ID: <20211101015155.GC25300@laputa> (raw)
In-Reply-To: <CAPnjgZ34hDL0VWKMm-CXUP5jfB+OCHN8j6WwMoDzc6S4C6oF7w@mail.gmail.com>
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
> <takahiro.akashi@linaro.org> 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 <sjg@chromium.org>:
> > > >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 Takahiro <takahiro.akashi@linaro.org>:
> > > >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
> > > >> >>
> > > >> >>
> > > >> >> > 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? 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 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 confusing
> > > >> >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 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 devices
> > > >> >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 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 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 uclasses and udevices.
> > > >>
> > > >> >I also remember that you claimed that not all efi objects(handles and
> > > >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to 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 enumerated is specific 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 complicated.)
> > > >> >
> > > >> >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 always 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 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 partition
> > > >| |-- Block device (UCLASS_BLK) - e.g. for a different HW partition*
> > > >
> > > >* 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 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 '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.
What should DM represent in U-Boot world?
> 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 software
> > > >> >> 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 exposes 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(). 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
next prev parent reply other threads:[~2021-11-01 1:52 UTC|newest]
Thread overview: 157+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 5:01 [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model AKASHI Takahiro
2021-10-01 5:01 ` [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC AKASHI Takahiro
2021-10-01 6:41 ` Heinrich Schuchardt
2021-10-01 7:56 ` Heinrich Schuchardt
2021-10-04 3:13 ` AKASHI Takahiro
2021-10-01 11:48 ` Peter Robinson
2021-10-04 3:26 ` AKASHI Takahiro
2021-10-11 10:07 ` Heinrich Schuchardt
2021-10-11 14:32 ` Simon Glass
2021-10-11 15:08 ` Heinrich Schuchardt
2021-10-11 16:14 ` Simon Glass
2021-10-12 3:26 ` AKASHI Takahiro
2021-10-12 13:30 ` Heinrich Schuchardt
2021-10-13 1:50 ` AKASHI Takahiro
2021-10-12 20:31 ` Simon Glass
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:01 ` [RFC 01/22] scsi: call device_probe() after scanning AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:01 ` [RFC 02/22] " AKASHI Takahiro
2021-10-01 5:01 ` [RFC 02/22] usb: storage: " AKASHI Takahiro
2021-10-01 5:01 ` [RFC 03/22] mmc: " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 1:10 ` AKASHI Takahiro
2021-10-01 5:01 ` [RFC 03/22] usb: storage: " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:01 ` [RFC 04/22] mmc: " AKASHI Takahiro
2021-10-01 5:01 ` [RFC 04/22] nvme: " AKASHI Takahiro
2021-10-01 5:01 ` [RFC 05/22] " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:01 ` [RFC 05/22] sata: " AKASHI Takahiro
2021-10-01 5:01 ` [RFC 06/22] block: ide: " AKASHI Takahiro
2021-10-01 5:01 ` [RFC 06/22] sata: " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 1:11 ` AKASHI Takahiro
2021-10-01 5:01 ` [RFC 07/22] block: ide: " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 1:43 ` AKASHI Takahiro
2021-10-11 14:54 ` Simon Glass
2021-10-12 5:53 ` Ilias Apalodimas
2021-10-13 0:35 ` AKASHI Takahiro
2021-10-01 5:01 ` [RFC 07/22] dm: blk: add UCLASS_PARTITION AKASHI Takahiro
2021-10-01 9:30 ` Heinrich Schuchardt
2021-10-04 3:27 ` AKASHI Takahiro
2021-10-08 0:51 ` AKASHI Takahiro
2021-10-08 8:23 ` Heinrich Schuchardt
2021-10-11 2:29 ` AKASHI Takahiro
2021-10-11 14:54 ` Simon Glass
2021-10-11 15:02 ` Heinrich Schuchardt
2021-10-11 16:14 ` Simon Glass
2021-10-11 16:48 ` Heinrich Schuchardt
2021-10-11 17:41 ` Simon Glass
2021-10-12 5:12 ` AKASHI Takahiro
2021-10-12 6:42 ` Heinrich Schuchardt
2021-10-12 15:14 ` Tom Rini
2021-10-13 1:32 ` AKASHI Takahiro
2021-10-13 18:05 ` Simon Glass
2021-10-14 8:03 ` AKASHI Takahiro
2021-10-14 20:55 ` Simon Glass
2021-10-28 8:52 ` AKASHI Takahiro
2021-10-28 10:42 ` Heinrich Schuchardt
2021-10-29 1:45 ` Simon Glass
2021-10-29 4:57 ` Heinrich Schuchardt
2021-10-29 6:15 ` AKASHI Takahiro
2021-10-29 19:21 ` Heinrich Schuchardt
2021-10-29 21:17 ` Simon Glass
2021-10-30 5:45 ` Heinrich Schuchardt
2021-11-01 0:36 ` AKASHI Takahiro
2021-11-01 1:15 ` Simon Glass
2021-11-01 1:51 ` AKASHI Takahiro [this message]
2021-11-01 2:14 ` Simon Glass
2021-11-02 1:42 ` AKASHI Takahiro
2021-11-02 7:38 ` Heinrich Schuchardt
2021-11-05 2:02 ` Simon Glass
2021-11-05 2:49 ` AKASHI Takahiro
2021-11-05 16:12 ` Simon Glass
2021-11-08 4:46 ` AKASHI Takahiro
2021-11-08 18:44 ` Ilias Apalodimas
2021-11-09 0:09 ` Simon Glass
2021-11-13 18:14 ` Simon Glass
2021-11-13 18:37 ` Heinrich Schuchardt
2021-11-13 21:32 ` Simon Glass
2021-11-15 1:43 ` AKASHI Takahiro
2021-11-15 19:05 ` Simon Glass
2021-11-15 19:16 ` Heinrich Schuchardt
2021-11-15 23:51 ` AKASHI Takahiro
2021-11-16 0:02 ` Heinrich Schuchardt
2021-11-16 3:01 ` AKASHI Takahiro
2021-12-03 7:16 ` AKASHI Takahiro
2021-12-03 16:06 ` Heinrich Schuchardt
2021-12-06 4:18 ` AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-12 3:53 ` AKASHI Takahiro
2021-10-01 5:01 ` [RFC 08/22] " AKASHI Takahiro
2021-10-01 9:32 ` Heinrich Schuchardt
2021-10-01 5:02 ` [RFC 08/22] dm: blk: add a device-probe hook for scanning disk partitions AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 09/22] " AKASHI Takahiro
2021-10-01 5:02 ` [RFC 09/22] dm: blk: add read/write interfaces with udevice AKASHI Takahiro
2021-10-01 5:02 ` [RFC 10/22] " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 10/22] efi_loader: disk: use udevice instead of blk_desc AKASHI Takahiro
2021-10-01 5:02 ` [RFC 11/22] dm: add a hidden link to efi object AKASHI Takahiro
2021-10-01 5:02 ` [RFC 11/22] efi_loader: disk: use udevice instead of blk_desc AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 12/22] dm: add a hidden link to efi object AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 6:43 ` AKASHI Takahiro
2021-10-11 14:54 ` Simon Glass
2021-10-11 15:26 ` Heinrich Schuchardt
2021-10-11 16:09 ` Simon Glass
2021-10-12 2:09 ` AKASHI Takahiro
2021-10-12 20:31 ` Simon Glass
2021-10-01 5:02 ` [RFC 12/22] efi_loader: remove !CONFIG_BLK code from efi_disk AKASHI Takahiro
2021-10-01 5:02 ` [RFC 13/22] efi_loader: disk: a helper function to create efi_disk objects from udevice AKASHI Takahiro
2021-10-01 5:02 ` [RFC 13/22] efi_loader: remove !CONFIG_BLK code from efi_disk AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 14/22] dm: blk: call efi's device-probe hook AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 3:15 ` AKASHI Takahiro
2021-10-11 14:54 ` Simon Glass
2021-11-01 3:03 ` Simon Glass
2021-10-01 5:02 ` [RFC 14/22] efi_loader: disk: a helper function to create efi_disk objects from udevice AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 6:52 ` AKASHI Takahiro
2021-10-11 14:54 ` Simon Glass
2021-10-12 1:09 ` AKASHI Takahiro
2021-10-12 14:08 ` Simon Glass
2021-10-01 5:02 ` [RFC 15/22] dm: blk: call efi's device-probe hook AKASHI Takahiro
2021-10-01 5:02 ` [RFC 15/22] efi_loader: cleanup after efi_disk-dm integration AKASHI Takahiro
2021-10-01 5:02 ` [RFC 16/22] efi_loader: add efi_remove_handle() AKASHI Takahiro
2021-10-01 5:02 ` [RFC 16/22] efi_loader: cleanup after efi_disk-dm integration AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 17/22] efi_loader: add efi_remove_handle() AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 17/22] efi_loader: efi_disk: a helper function to delete efi_disk objects AKASHI Takahiro
2021-10-01 5:02 ` [RFC 18/22] dm: blk: call efi's device-removal hook AKASHI Takahiro
2021-10-01 5:02 ` [RFC 18/22] efi_loader: efi_disk: a helper function to delete efi_disk objects AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 19/22] dm: blk: call efi's device-removal hook AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 19/22] efi_driver: align with efi_disk-dm integration AKASHI Takahiro
2021-10-01 5:02 ` [RFC 20/22] " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-11 7:41 ` AKASHI Takahiro
2021-10-01 5:02 ` [RFC 20/22] efi_driver: cleanup after " AKASHI Takahiro
2021-10-01 5:02 ` [RFC 21/22] " AKASHI Takahiro
2021-10-10 14:14 ` Simon Glass
2021-10-01 5:02 ` [RFC 21/22] efi_selftest: block device: adjust dp for a test disk AKASHI Takahiro
2021-10-01 5:02 ` [RFC 22/22] (TEST) let dm-tree unchanged after block_io testing is done AKASHI Takahiro
2021-10-01 5:02 ` [RFC 22/22] efi_selftest: block device: adjust dp for a test disk AKASHI Takahiro
2021-10-02 14:17 ` Heinrich Schuchardt
2021-10-10 14:14 ` [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model Simon Glass
2021-10-12 15:00 ` Tom Rini
2021-10-12 20:31 ` Simon Glass
2021-10-12 21:13 ` Tom Rini
2021-10-12 23:37 ` Simon Glass
2021-10-12 23:40 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211101015155.GC25300@laputa \
--to=takahiro.akashi@linaro.org \
--cc=agraf@csgraf.de \
--cc=ilias.apalodimas@linaro.org \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox