diff mbox series

[RFC,07/22] dm: blk: add UCLASS_PARTITION

Message ID	20211001050228.55183-15-takahiro.akashi@linaro.org
State	Superseded
Headers	show Delivered-To: patch@linaro.org Received-SPF: pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; From: AKASHI Takahiro <takahiro.akashi@linaro.org> To: xypron.glpk@gmx.de, agraf@csgraf.de, sjg@chromium.org, ilias.apalodimas@linaro.org Cc: u-boot@lists.denx.de, AKASHI Takahiro <takahiro.akashi@linaro.org> Subject: [RFC 07/22] dm: blk: add UCLASS_PARTITION Date: Fri, 1 Oct 2021 14:01:58 +0900 Message-Id: <20211001050228.55183-15-takahiro.akashi@linaro.org> In-Reply-To: <20211001050228.55183-1-takahiro.akashi@linaro.org> References: <20211001050228.55183-1-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: list Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" <u-boot-bounces@lists.denx.de>
Series	None \| expand [RFC,07/22] dm: blk: add UCLASS_PARTITION

Commit Message

AKASHI Takahiro Oct. 1, 2021, 5:01 a.m. UTC

UCLASS_PARTITION device will be created as a child node of
UCLASS_BLK device.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

---
 drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++
 include/blk.h              |   9 +++
 include/dm/uclass-id.h     |   1 +
 3 files changed, 121 insertions(+)

-- 
2.33.0

Comments

Heinrich Schuchardt Oct. 1, 2021, 9:30 a.m. UTC | #1

On 10/1/21 07:01, AKASHI Takahiro wrote:
> UCLASS_PARTITION device will be created as a child node of

> UCLASS_BLK device.

>

> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> ---

>   drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>   include/blk.h              |   9 +++

>   include/dm/uclass-id.h     |   1 +

>   3 files changed, 121 insertions(+)

>

> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> index 83682dcc181a..dd7f3c0fe31e 100644

> --- a/drivers/block/blk-uclass.c

> +++ b/drivers/block/blk-uclass.c

> @@ -12,6 +12,7 @@

>   #include <log.h>

>   #include <malloc.h>

>   #include <part.h>

> +#include <string.h>

>   #include <dm/device-internal.h>

>   #include <dm/lists.h>

>   #include <dm/uclass-internal.h>

> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>   	return 0;

>   }

>

> +int blk_create_partitions(struct udevice *parent)

> +{

> +	int part, count;

> +	struct blk_desc *desc = dev_get_uclass_plat(parent);

> +	struct disk_partition info;

> +	struct disk_part *part_data;

> +	char devname[32];

> +	struct udevice *dev;

> +	int ret;

> +

> +	if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> +	    !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> +		return 0;

> +

> +	/* Add devices for each partition */

> +	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> +		if (part_get_info(desc, part, &info))

> +			continue;

> +		snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> +			 part);

> +

> +		ret = device_bind_driver(parent, "blk_partition",

> +					 strdup(devname), &dev);

> +		if (ret)

> +			return ret;

> +

> +		part_data = dev_get_uclass_plat(dev);

> +		part_data->partnum = part;

> +		part_data->gpt_part_info = info;

> +		count++;

> +

> +		device_probe(dev);

> +	}

> +	debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> +

> +	return 0;

> +}

> +

>   static int blk_post_probe(struct udevice *dev)

>   {

>   	if (IS_ENABLED(CONFIG_PARTITIONS) &&

> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>   	.post_probe	= blk_post_probe,

>   	.per_device_plat_auto	= sizeof(struct blk_desc),

>   };

> +

> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> +			   lbaint_t blkcnt, void *buffer)

> +{

> +	struct udevice *parent;

> +	struct disk_part *part;

> +	const struct blk_ops *ops;

> +

> +	parent = dev_get_parent(dev);


What device type will the parent have if it is a eMMC hardware partition?

> +	ops = blk_get_ops(parent);

> +	if (!ops->read)

> +		return -ENOSYS;

> +

> +	part = dev_get_uclass_plat(dev);


You should check that we do not access the block device past the
partition end:

struct blk_desc *desc = dev_get_uclass_plat(parent);
if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)
	return -EFAULT.

> +	start += part->gpt_part_info.start;

> +

> +	return ops->read(parent, start, blkcnt, buffer);

> +}

> +

> +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

> +			    lbaint_t blkcnt, const void *buffer)

> +{

> +	struct udevice *parent;

> +	struct disk_part *part;

> +	const struct blk_ops *ops;

> +

> +	parent = dev_get_parent(dev);

> +	ops = blk_get_ops(parent);

> +	if (!ops->write)

> +		return -ENOSYS;

> +

> +	part = dev_get_uclass_plat(dev);

> +	start += part->gpt_part_info.start;


here too

> +

> +	return ops->write(parent, start, blkcnt, buffer);

> +}

> +

> +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

> +			    lbaint_t blkcnt)

> +{

> +	struct udevice *parent;

> +	struct disk_part *part;

> +	const struct blk_ops *ops;

> +

> +	parent = dev_get_parent(dev);

> +	ops = blk_get_ops(parent);

> +	if (!ops->erase)

> +		return -ENOSYS;

> +

> +	part = dev_get_uclass_plat(dev);

> +	start += part->gpt_part_info.start;


here too

Best regards

Heinrich

> +

> +	return ops->erase(parent, start, blkcnt);

> +}

> +

> +static const struct blk_ops blk_part_ops = {

> +	.read	= blk_part_read,

> +	.write	= blk_part_write,

> +	.erase	= blk_part_erase,

> +};

> +

> +U_BOOT_DRIVER(blk_partition) = {

> +	.name		= "blk_partition",

> +	.id		= UCLASS_PARTITION,

> +	.ops		= &blk_part_ops,

> +};

> +

> +UCLASS_DRIVER(partition) = {

> +	.id		= UCLASS_PARTITION,

> +	.per_device_plat_auto	= sizeof(struct disk_part),

> +	.name		= "partition",

> +};

> diff --git a/include/blk.h b/include/blk.h

> index 19bab081c2cd..3d883eb1db64 100644

> --- a/include/blk.h

> +++ b/include/blk.h

> @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

>   		       const char *name, int if_type, int devnum, int blksz,

>   		       lbaint_t lba, struct udevice **devp);

>

> +/**

> + * blk_create_partitions - Create block devices for disk partitions

> + *

> + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

> + *

> + * @parent:	Whole disk device

> + */

> +int blk_create_partitions(struct udevice *parent);

> +

>   /**

>    * blk_unbind_all() - Unbind all device of the given interface type

>    *

> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

> index e7edd409f307..30892d01ce13 100644

> --- a/include/dm/uclass-id.h

> +++ b/include/dm/uclass-id.h

> @@ -80,6 +80,7 @@ enum uclass_id {

>   	UCLASS_P2SB,		/* (x86) Primary-to-Sideband Bus */

>   	UCLASS_PANEL,		/* Display panel, such as an LCD */

>   	UCLASS_PANEL_BACKLIGHT,	/* Backlight controller for panel */

> +	UCLASS_PARTITION,	/* Logical disk partition device */

>   	UCLASS_PCH,		/* x86 platform controller hub */

>   	UCLASS_PCI,		/* PCI bus */

>   	UCLASS_PCI_EP,		/* PCI endpoint device */

>

AKASHI Takahiro Oct. 4, 2021, 3:27 a.m. UTC | #2

On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:
> 

> 

> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > UCLASS_PARTITION device will be created as a child node of

> > UCLASS_BLK device.

> > 

> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > ---

> >   drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> >   include/blk.h              |   9 +++

> >   include/dm/uclass-id.h     |   1 +

> >   3 files changed, 121 insertions(+)

> > 

> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > index 83682dcc181a..dd7f3c0fe31e 100644

> > --- a/drivers/block/blk-uclass.c

> > +++ b/drivers/block/blk-uclass.c

> > @@ -12,6 +12,7 @@

> >   #include <log.h>

> >   #include <malloc.h>

> >   #include <part.h>

> > +#include <string.h>

> >   #include <dm/device-internal.h>

> >   #include <dm/lists.h>

> >   #include <dm/uclass-internal.h>

> > @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> >   	return 0;

> >   }

> > 

> > +int blk_create_partitions(struct udevice *parent)

> > +{

> > +	int part, count;

> > +	struct blk_desc *desc = dev_get_uclass_plat(parent);

> > +	struct disk_partition info;

> > +	struct disk_part *part_data;

> > +	char devname[32];

> > +	struct udevice *dev;

> > +	int ret;

> > +

> > +	if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > +	    !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > +		return 0;

> > +

> > +	/* Add devices for each partition */

> > +	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > +		if (part_get_info(desc, part, &info))

> > +			continue;

> > +		snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > +			 part);

> > +

> > +		ret = device_bind_driver(parent, "blk_partition",

> > +					 strdup(devname), &dev);

> > +		if (ret)

> > +			return ret;

> > +

> > +		part_data = dev_get_uclass_plat(dev);

> > +		part_data->partnum = part;

> > +		part_data->gpt_part_info = info;

> > +		count++;

> > +

> > +		device_probe(dev);

> > +	}

> > +	debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > +

> > +	return 0;

> > +}

> > +

> >   static int blk_post_probe(struct udevice *dev)

> >   {

> >   	if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> >   	.post_probe	= blk_post_probe,

> >   	.per_device_plat_auto	= sizeof(struct blk_desc),

> >   };

> > +

> > +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > +			   lbaint_t blkcnt, void *buffer)

> > +{

> > +	struct udevice *parent;

> > +	struct disk_part *part;

> > +	const struct blk_ops *ops;

> > +

> > +	parent = dev_get_parent(dev);

> 

> What device type will the parent have if it is a eMMC hardware partition?

> 

> > +	ops = blk_get_ops(parent);

> > +	if (!ops->read)

> > +		return -ENOSYS;

> > +

> > +	part = dev_get_uclass_plat(dev);

> 

> You should check that we do not access the block device past the

> partition end:


Yes, I will fix all of checks.

-Takahiro Akashi

> struct blk_desc *desc = dev_get_uclass_plat(parent);

> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> 	return -EFAULT.

> 

> > +	start += part->gpt_part_info.start;

> > +

> > +	return ops->read(parent, start, blkcnt, buffer);

> > +}

> > +

> > +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

> > +			    lbaint_t blkcnt, const void *buffer)

> > +{

> > +	struct udevice *parent;

> > +	struct disk_part *part;

> > +	const struct blk_ops *ops;

> > +

> > +	parent = dev_get_parent(dev);

> > +	ops = blk_get_ops(parent);

> > +	if (!ops->write)

> > +		return -ENOSYS;

> > +

> > +	part = dev_get_uclass_plat(dev);

> > +	start += part->gpt_part_info.start;

> 

> here too

> 

> > +

> > +	return ops->write(parent, start, blkcnt, buffer);

> > +}

> > +

> > +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

> > +			    lbaint_t blkcnt)

> > +{

> > +	struct udevice *parent;

> > +	struct disk_part *part;

> > +	const struct blk_ops *ops;

> > +

> > +	parent = dev_get_parent(dev);

> > +	ops = blk_get_ops(parent);

> > +	if (!ops->erase)

> > +		return -ENOSYS;

> > +

> > +	part = dev_get_uclass_plat(dev);

> > +	start += part->gpt_part_info.start;

> 

> here too

> 

> Best regards

> 

> Heinrich

> 

> > +

> > +	return ops->erase(parent, start, blkcnt);

> > +}

> > +

> > +static const struct blk_ops blk_part_ops = {

> > +	.read	= blk_part_read,

> > +	.write	= blk_part_write,

> > +	.erase	= blk_part_erase,

> > +};

> > +

> > +U_BOOT_DRIVER(blk_partition) = {

> > +	.name		= "blk_partition",

> > +	.id		= UCLASS_PARTITION,

> > +	.ops		= &blk_part_ops,

> > +};

> > +

> > +UCLASS_DRIVER(partition) = {

> > +	.id		= UCLASS_PARTITION,

> > +	.per_device_plat_auto	= sizeof(struct disk_part),

> > +	.name		= "partition",

> > +};

> > diff --git a/include/blk.h b/include/blk.h

> > index 19bab081c2cd..3d883eb1db64 100644

> > --- a/include/blk.h

> > +++ b/include/blk.h

> > @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

> >   		       const char *name, int if_type, int devnum, int blksz,

> >   		       lbaint_t lba, struct udevice **devp);

> > 

> > +/**

> > + * blk_create_partitions - Create block devices for disk partitions

> > + *

> > + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

> > + *

> > + * @parent:	Whole disk device

> > + */

> > +int blk_create_partitions(struct udevice *parent);

> > +

> >   /**

> >    * blk_unbind_all() - Unbind all device of the given interface type

> >    *

> > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

> > index e7edd409f307..30892d01ce13 100644

> > --- a/include/dm/uclass-id.h

> > +++ b/include/dm/uclass-id.h

> > @@ -80,6 +80,7 @@ enum uclass_id {

> >   	UCLASS_P2SB,		/* (x86) Primary-to-Sideband Bus */

> >   	UCLASS_PANEL,		/* Display panel, such as an LCD */

> >   	UCLASS_PANEL_BACKLIGHT,	/* Backlight controller for panel */

> > +	UCLASS_PARTITION,	/* Logical disk partition device */

> >   	UCLASS_PCH,		/* x86 platform controller hub */

> >   	UCLASS_PCI,		/* PCI bus */

> >   	UCLASS_PCI_EP,		/* PCI endpoint device */

> >

AKASHI Takahiro Oct. 8, 2021, 12:51 a.m. UTC | #3

On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:
> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > 

> > 

> > On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > UCLASS_PARTITION device will be created as a child node of

> > > UCLASS_BLK device.

> > > 

> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > ---

> > >   drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > >   include/blk.h              |   9 +++

> > >   include/dm/uclass-id.h     |   1 +

> > >   3 files changed, 121 insertions(+)

> > > 

> > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > index 83682dcc181a..dd7f3c0fe31e 100644

> > > --- a/drivers/block/blk-uclass.c

> > > +++ b/drivers/block/blk-uclass.c

> > > @@ -12,6 +12,7 @@

> > >   #include <log.h>

> > >   #include <malloc.h>

> > >   #include <part.h>

> > > +#include <string.h>

> > >   #include <dm/device-internal.h>

> > >   #include <dm/lists.h>

> > >   #include <dm/uclass-internal.h>

> > > @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > >   	return 0;

> > >   }

> > > 

> > > +int blk_create_partitions(struct udevice *parent)

> > > +{

> > > +	int part, count;

> > > +	struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > +	struct disk_partition info;

> > > +	struct disk_part *part_data;

> > > +	char devname[32];

> > > +	struct udevice *dev;

> > > +	int ret;

> > > +

> > > +	if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > +	    !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > +		return 0;

> > > +

> > > +	/* Add devices for each partition */

> > > +	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > +		if (part_get_info(desc, part, &info))

> > > +			continue;

> > > +		snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > +			 part);

> > > +

> > > +		ret = device_bind_driver(parent, "blk_partition",

> > > +					 strdup(devname), &dev);

> > > +		if (ret)

> > > +			return ret;

> > > +

> > > +		part_data = dev_get_uclass_plat(dev);

> > > +		part_data->partnum = part;

> > > +		part_data->gpt_part_info = info;

> > > +		count++;

> > > +

> > > +		device_probe(dev);

> > > +	}

> > > +	debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > +

> > > +	return 0;

> > > +}

> > > +

> > >   static int blk_post_probe(struct udevice *dev)

> > >   {

> > >   	if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > >   	.post_probe	= blk_post_probe,

> > >   	.per_device_plat_auto	= sizeof(struct blk_desc),

> > >   };

> > > +

> > > +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > +			   lbaint_t blkcnt, void *buffer)

> > > +{

> > > +	struct udevice *parent;

> > > +	struct disk_part *part;

> > > +	const struct blk_ops *ops;

> > > +

> > > +	parent = dev_get_parent(dev);

> > 

> > What device type will the parent have if it is a eMMC hardware partition?

> > 

> > > +	ops = blk_get_ops(parent);

> > > +	if (!ops->read)

> > > +		return -ENOSYS;

> > > +

> > > +	part = dev_get_uclass_plat(dev);

> > 

> > You should check that we do not access the block device past the

> > partition end:

> 

> Yes, I will fix all of checks.

> 

> > struct blk_desc *desc = dev_get_uclass_plat(parent);

> > if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > 	return -EFAULT.

> > 

> > > +	start += part->gpt_part_info.start;


A better solution is:
        if (start >= part->gpt_part_info.size)
                return 0;

        if ((start + blkcnt) > part->gpt_part_info.size)
                blkcnt = part->gpt_part_info.size - start;
        start += part->gpt_part_info.start;
instead of returning -EFAULT.
(note that start and blkcnt are in "block".)

-Takahiro Akashi

> > > +

> > > +	return ops->read(parent, start, blkcnt, buffer);

> > > +}

> > > +

> > > +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

> > > +			    lbaint_t blkcnt, const void *buffer)

> > > +{

> > > +	struct udevice *parent;

> > > +	struct disk_part *part;

> > > +	const struct blk_ops *ops;

> > > +

> > > +	parent = dev_get_parent(dev);

> > > +	ops = blk_get_ops(parent);

> > > +	if (!ops->write)

> > > +		return -ENOSYS;

> > > +

> > > +	part = dev_get_uclass_plat(dev);

> > > +	start += part->gpt_part_info.start;

> > 

> > here too

> > 

> > > +

> > > +	return ops->write(parent, start, blkcnt, buffer);

> > > +}

> > > +

> > > +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

> > > +			    lbaint_t blkcnt)

> > > +{

> > > +	struct udevice *parent;

> > > +	struct disk_part *part;

> > > +	const struct blk_ops *ops;

> > > +

> > > +	parent = dev_get_parent(dev);

> > > +	ops = blk_get_ops(parent);

> > > +	if (!ops->erase)

> > > +		return -ENOSYS;

> > > +

> > > +	part = dev_get_uclass_plat(dev);

> > > +	start += part->gpt_part_info.start;

> > 

> > here too

> > 

> > Best regards

> > 

> > Heinrich

> > 

> > > +

> > > +	return ops->erase(parent, start, blkcnt);

> > > +}

> > > +

> > > +static const struct blk_ops blk_part_ops = {

> > > +	.read	= blk_part_read,

> > > +	.write	= blk_part_write,

> > > +	.erase	= blk_part_erase,

> > > +};

> > > +

> > > +U_BOOT_DRIVER(blk_partition) = {

> > > +	.name		= "blk_partition",

> > > +	.id		= UCLASS_PARTITION,

> > > +	.ops		= &blk_part_ops,

> > > +};

> > > +

> > > +UCLASS_DRIVER(partition) = {

> > > +	.id		= UCLASS_PARTITION,

> > > +	.per_device_plat_auto	= sizeof(struct disk_part),

> > > +	.name		= "partition",

> > > +};

> > > diff --git a/include/blk.h b/include/blk.h

> > > index 19bab081c2cd..3d883eb1db64 100644

> > > --- a/include/blk.h

> > > +++ b/include/blk.h

> > > @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

> > >   		       const char *name, int if_type, int devnum, int blksz,

> > >   		       lbaint_t lba, struct udevice **devp);

> > > 

> > > +/**

> > > + * blk_create_partitions - Create block devices for disk partitions

> > > + *

> > > + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

> > > + *

> > > + * @parent:	Whole disk device

> > > + */

> > > +int blk_create_partitions(struct udevice *parent);

> > > +

> > >   /**

> > >    * blk_unbind_all() - Unbind all device of the given interface type

> > >    *

> > > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

> > > index e7edd409f307..30892d01ce13 100644

> > > --- a/include/dm/uclass-id.h

> > > +++ b/include/dm/uclass-id.h

> > > @@ -80,6 +80,7 @@ enum uclass_id {

> > >   	UCLASS_P2SB,		/* (x86) Primary-to-Sideband Bus */

> > >   	UCLASS_PANEL,		/* Display panel, such as an LCD */

> > >   	UCLASS_PANEL_BACKLIGHT,	/* Backlight controller for panel */

> > > +	UCLASS_PARTITION,	/* Logical disk partition device */

> > >   	UCLASS_PCH,		/* x86 platform controller hub */

> > >   	UCLASS_PCI,		/* PCI bus */

> > >   	UCLASS_PCI_EP,		/* PCI endpoint device */

> > >

Heinrich Schuchardt Oct. 8, 2021, 8:23 a.m. UTC | #4

On 10/8/21 02:51, AKASHI Takahiro wrote:
> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

>>>

>>>

>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

>>>> UCLASS_PARTITION device will be created as a child node of

>>>> UCLASS_BLK device.

>>>>

>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

>>>> ---

>>>>    drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>>>>    include/blk.h              |   9 +++

>>>>    include/dm/uclass-id.h     |   1 +

>>>>    3 files changed, 121 insertions(+)

>>>>

>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

>>>> index 83682dcc181a..dd7f3c0fe31e 100644

>>>> --- a/drivers/block/blk-uclass.c

>>>> +++ b/drivers/block/blk-uclass.c

>>>> @@ -12,6 +12,7 @@

>>>>    #include <log.h>

>>>>    #include <malloc.h>

>>>>    #include <part.h>

>>>> +#include <string.h>

>>>>    #include <dm/device-internal.h>

>>>>    #include <dm/lists.h>

>>>>    #include <dm/uclass-internal.h>

>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>>>>    	return 0;

>>>>    }

>>>>

>>>> +int blk_create_partitions(struct udevice *parent)

>>>> +{

>>>> +	int part, count;

>>>> +	struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>> +	struct disk_partition info;

>>>> +	struct disk_part *part_data;

>>>> +	char devname[32];

>>>> +	struct udevice *dev;

>>>> +	int ret;

>>>> +

>>>> +	if (!CONFIG_IS_ENABLED(PARTITIONS) ||

>>>> +	    !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

>>>> +		return 0;

>>>> +

>>>> +	/* Add devices for each partition */

>>>> +	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

>>>> +		if (part_get_info(desc, part, &info))

>>>> +			continue;

>>>> +		snprintf(devname, sizeof(devname), "%s:%d", parent->name,

>>>> +			 part);

>>>> +

>>>> +		ret = device_bind_driver(parent, "blk_partition",

>>>> +					 strdup(devname), &dev);

>>>> +		if (ret)

>>>> +			return ret;

>>>> +

>>>> +		part_data = dev_get_uclass_plat(dev);

>>>> +		part_data->partnum = part;

>>>> +		part_data->gpt_part_info = info;

>>>> +		count++;

>>>> +

>>>> +		device_probe(dev);

>>>> +	}

>>>> +	debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

>>>> +

>>>> +	return 0;

>>>> +}

>>>> +

>>>>    static int blk_post_probe(struct udevice *dev)

>>>>    {

>>>>    	if (IS_ENABLED(CONFIG_PARTITIONS) &&

>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>>>>    	.post_probe	= blk_post_probe,

>>>>    	.per_device_plat_auto	= sizeof(struct blk_desc),

>>>>    };

>>>> +

>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

>>>> +			   lbaint_t blkcnt, void *buffer)

>>>> +{

>>>> +	struct udevice *parent;

>>>> +	struct disk_part *part;

>>>> +	const struct blk_ops *ops;

>>>> +

>>>> +	parent = dev_get_parent(dev);

>>>

>>> What device type will the parent have if it is a eMMC hardware partition?

>>>

>>>> +	ops = blk_get_ops(parent);

>>>> +	if (!ops->read)

>>>> +		return -ENOSYS;

>>>> +

>>>> +	part = dev_get_uclass_plat(dev);

>>>

>>> You should check that we do not access the block device past the

>>> partition end:

>>

>> Yes, I will fix all of checks.

>>

>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

>>> 	return -EFAULT.

>>>

>>>> +	start += part->gpt_part_info.start;

>

> A better solution is:

>          if (start >= part->gpt_part_info.size)

>                  return 0;

>

>          if ((start + blkcnt) > part->gpt_part_info.size)

>                  blkcnt = part->gpt_part_info.size - start;

>          start += part->gpt_part_info.start;

> instead of returning -EFAULT.

> (note that start and blkcnt are in "block".)


What is your motivation to support an illegal access?

We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The
ReadBlocks() and WriteBlocks() services must return
EFI_INVALID_PARAMETER if the read request contains LBAs that are not
valid. So we should return an error code here that can be translated
into EFI_INVALID_PARAMETER.

Best regards

Heinrich

>

> -Takahiro Akashi

>

>>>> +

>>>> +	return ops->read(parent, start, blkcnt, buffer);

>>>> +}

>>>> +

>>>> +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

>>>> +			    lbaint_t blkcnt, const void *buffer)

>>>> +{

>>>> +	struct udevice *parent;

>>>> +	struct disk_part *part;

>>>> +	const struct blk_ops *ops;

>>>> +

>>>> +	parent = dev_get_parent(dev);

>>>> +	ops = blk_get_ops(parent);

>>>> +	if (!ops->write)

>>>> +		return -ENOSYS;

>>>> +

>>>> +	part = dev_get_uclass_plat(dev);

>>>> +	start += part->gpt_part_info.start;

>>>

>>> here too

>>>

>>>> +

>>>> +	return ops->write(parent, start, blkcnt, buffer);

>>>> +}

>>>> +

>>>> +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

>>>> +			    lbaint_t blkcnt)

>>>> +{

>>>> +	struct udevice *parent;

>>>> +	struct disk_part *part;

>>>> +	const struct blk_ops *ops;

>>>> +

>>>> +	parent = dev_get_parent(dev);

>>>> +	ops = blk_get_ops(parent);

>>>> +	if (!ops->erase)

>>>> +		return -ENOSYS;

>>>> +

>>>> +	part = dev_get_uclass_plat(dev);

>>>> +	start += part->gpt_part_info.start;

>>>

>>> here too

>>>

>>> Best regards

>>>

>>> Heinrich

>>>

>>>> +

>>>> +	return ops->erase(parent, start, blkcnt);

>>>> +}

>>>> +

>>>> +static const struct blk_ops blk_part_ops = {

>>>> +	.read	= blk_part_read,

>>>> +	.write	= blk_part_write,

>>>> +	.erase	= blk_part_erase,

>>>> +};

>>>> +

>>>> +U_BOOT_DRIVER(blk_partition) = {

>>>> +	.name		= "blk_partition",

>>>> +	.id		= UCLASS_PARTITION,

>>>> +	.ops		= &blk_part_ops,

>>>> +};

>>>> +

>>>> +UCLASS_DRIVER(partition) = {

>>>> +	.id		= UCLASS_PARTITION,

>>>> +	.per_device_plat_auto	= sizeof(struct disk_part),

>>>> +	.name		= "partition",

>>>> +};

>>>> diff --git a/include/blk.h b/include/blk.h

>>>> index 19bab081c2cd..3d883eb1db64 100644

>>>> --- a/include/blk.h

>>>> +++ b/include/blk.h

>>>> @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

>>>>    		       const char *name, int if_type, int devnum, int blksz,

>>>>    		       lbaint_t lba, struct udevice **devp);

>>>>

>>>> +/**

>>>> + * blk_create_partitions - Create block devices for disk partitions

>>>> + *

>>>> + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

>>>> + *

>>>> + * @parent:	Whole disk device

>>>> + */

>>>> +int blk_create_partitions(struct udevice *parent);

>>>> +

>>>>    /**

>>>>     * blk_unbind_all() - Unbind all device of the given interface type

>>>>     *

>>>> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

>>>> index e7edd409f307..30892d01ce13 100644

>>>> --- a/include/dm/uclass-id.h

>>>> +++ b/include/dm/uclass-id.h

>>>> @@ -80,6 +80,7 @@ enum uclass_id {

>>>>    	UCLASS_P2SB,		/* (x86) Primary-to-Sideband Bus */

>>>>    	UCLASS_PANEL,		/* Display panel, such as an LCD */

>>>>    	UCLASS_PANEL_BACKLIGHT,	/* Backlight controller for panel */

>>>> +	UCLASS_PARTITION,	/* Logical disk partition device */

>>>>    	UCLASS_PCH,		/* x86 platform controller hub */

>>>>    	UCLASS_PCI,		/* PCI bus */

>>>>    	UCLASS_PCI_EP,		/* PCI endpoint device */

>>>>

Simon Glass Oct. 10, 2021, 2:14 p.m. UTC | #5

Hi Takahiro,

On Thu, 30 Sept 2021 at 23:03, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>

> UCLASS_PARTITION device will be created as a child node of

> UCLASS_BLK device.

>

> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> ---

>  drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>  include/blk.h              |   9 +++

>  include/dm/uclass-id.h     |   1 +

>  3 files changed, 121 insertions(+)

>

> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> index 83682dcc181a..dd7f3c0fe31e 100644

> --- a/drivers/block/blk-uclass.c

> +++ b/drivers/block/blk-uclass.c

> @@ -12,6 +12,7 @@

>  #include <log.h>

>  #include <malloc.h>

>  #include <part.h>

> +#include <string.h>

>  #include <dm/device-internal.h>

>  #include <dm/lists.h>

>  #include <dm/uclass-internal.h>

> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>         return 0;

>  }

>

> +int blk_create_partitions(struct udevice *parent)

> +{

> +       int part, count;

> +       struct blk_desc *desc = dev_get_uclass_plat(parent);

> +       struct disk_partition info;

> +       struct disk_part *part_data;

> +       char devname[32];

> +       struct udevice *dev;

> +       int ret;

> +

> +       if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> +           !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> +               return 0;

> +

> +       /* Add devices for each partition */

> +       for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> +               if (part_get_info(desc, part, &info))

> +                       continue;

> +               snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> +                        part);

> +

> +               ret = device_bind_driver(parent, "blk_partition",

> +                                        strdup(devname), &dev);

> +               if (ret)

> +                       return ret;

> +

> +               part_data = dev_get_uclass_plat(dev);

> +               part_data->partnum = part;

> +               part_data->gpt_part_info = info;

> +               count++;

> +

> +               device_probe(dev);

> +       }

> +       debug("%s: %d partitions found in %s\n", __func__, count, parent->name);


log_debug() and drop __func__

> +

> +       return 0;

> +}

> +

>  static int blk_post_probe(struct udevice *dev)

>  {

>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>         .post_probe     = blk_post_probe,

>         .per_device_plat_auto   = sizeof(struct blk_desc),

>  };

> +

> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> +                          lbaint_t blkcnt, void *buffer)

> +{


part_blk_read() so that it is clear that this takes a UCLASS_PARTITION
device, not a UCLASS_BLK

> +       struct udevice *parent;

> +       struct disk_part *part;

> +       const struct blk_ops *ops;

> +

> +       parent = dev_get_parent(dev);

> +       ops = blk_get_ops(parent);

> +       if (!ops->read)

> +               return -ENOSYS;

> +

> +       part = dev_get_uclass_plat(dev);

> +       start += part->gpt_part_info.start;

> +

> +       return ops->read(parent, start, blkcnt, buffer);

> +}

> +

> +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

> +                           lbaint_t blkcnt, const void *buffer)

> +{

> +       struct udevice *parent;

> +       struct disk_part *part;

> +       const struct blk_ops *ops;

> +

> +       parent = dev_get_parent(dev);

> +       ops = blk_get_ops(parent);

> +       if (!ops->write)

> +               return -ENOSYS;

> +

> +       part = dev_get_uclass_plat(dev);

> +       start += part->gpt_part_info.start;

> +

> +       return ops->write(parent, start, blkcnt, buffer);

> +}

> +

> +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

> +                           lbaint_t blkcnt)

> +{

> +       struct udevice *parent;

> +       struct disk_part *part;

> +       const struct blk_ops *ops;

> +

> +       parent = dev_get_parent(dev);

> +       ops = blk_get_ops(parent);

> +       if (!ops->erase)

> +               return -ENOSYS;

> +

> +       part = dev_get_uclass_plat(dev);

> +       start += part->gpt_part_info.start;

> +

> +       return ops->erase(parent, start, blkcnt);

> +}

> +

> +static const struct blk_ops blk_part_ops = {

> +       .read   = blk_part_read,

> +       .write  = blk_part_write,

> +       .erase  = blk_part_erase,

> +};

> +

> +U_BOOT_DRIVER(blk_partition) = {

> +       .name           = "blk_partition",

> +       .id             = UCLASS_PARTITION,

> +       .ops            = &blk_part_ops,

> +};


Can you put this all in a separate part-uclass.c file? This too:

> +

> +UCLASS_DRIVER(partition) = {

> +       .id             = UCLASS_PARTITION,

> +       .per_device_plat_auto   = sizeof(struct disk_part),

> +       .name           = "partition",

> +};

> diff --git a/include/blk.h b/include/blk.h

> index 19bab081c2cd..3d883eb1db64 100644

> --- a/include/blk.h

> +++ b/include/blk.h

> @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

>                        const char *name, int if_type, int devnum, int blksz,

>                        lbaint_t lba, struct udevice **devp);

>

> +/**

> + * blk_create_partitions - Create block devices for disk partitions

> + *

> + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

> + *

> + * @parent:    Whole disk device


UCLASS_BLK?

It is good to document the device types to avoid people getting confused later.

> + */

> +int blk_create_partitions(struct udevice *parent);

> +

>  /**

>   * blk_unbind_all() - Unbind all device of the given interface type

>   *

> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

> index e7edd409f307..30892d01ce13 100644

> --- a/include/dm/uclass-id.h

> +++ b/include/dm/uclass-id.h

> @@ -80,6 +80,7 @@ enum uclass_id {

>         UCLASS_P2SB,            /* (x86) Primary-to-Sideband Bus */

>         UCLASS_PANEL,           /* Display panel, such as an LCD */

>         UCLASS_PANEL_BACKLIGHT, /* Backlight controller for panel */

> +       UCLASS_PARTITION,       /* Logical disk partition device */

>         UCLASS_PCH,             /* x86 platform controller hub */

>         UCLASS_PCI,             /* PCI bus */

>         UCLASS_PCI_EP,          /* PCI endpoint device */

> --

> 2.33.0

>


This is a new uclass so needs a sandbox test.

Regards,
Simon

AKASHI Takahiro Oct. 11, 2021, 2:29 a.m. UTC | #6

Heinrich,

On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:
> 

> 

> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > > 

> > > > 

> > > > On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > > > UCLASS_PARTITION device will be created as a child node of

> > > > > UCLASS_BLK device.

> > > > > 

> > > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > > > ---

> > > > >    drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > > >    include/blk.h              |   9 +++

> > > > >    include/dm/uclass-id.h     |   1 +

> > > > >    3 files changed, 121 insertions(+)

> > > > > 

> > > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > > > index 83682dcc181a..dd7f3c0fe31e 100644

> > > > > --- a/drivers/block/blk-uclass.c

> > > > > +++ b/drivers/block/blk-uclass.c

> > > > > @@ -12,6 +12,7 @@

> > > > >    #include <log.h>

> > > > >    #include <malloc.h>

> > > > >    #include <part.h>

> > > > > +#include <string.h>

> > > > >    #include <dm/device-internal.h>

> > > > >    #include <dm/lists.h>

> > > > >    #include <dm/uclass-internal.h>

> > > > > @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > > >    	return 0;

> > > > >    }

> > > > > 

> > > > > +int blk_create_partitions(struct udevice *parent)

> > > > > +{

> > > > > +	int part, count;

> > > > > +	struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > +	struct disk_partition info;

> > > > > +	struct disk_part *part_data;

> > > > > +	char devname[32];

> > > > > +	struct udevice *dev;

> > > > > +	int ret;

> > > > > +

> > > > > +	if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > > > +	    !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > > > +		return 0;

> > > > > +

> > > > > +	/* Add devices for each partition */

> > > > > +	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > > > +		if (part_get_info(desc, part, &info))

> > > > > +			continue;

> > > > > +		snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > > > +			 part);

> > > > > +

> > > > > +		ret = device_bind_driver(parent, "blk_partition",

> > > > > +					 strdup(devname), &dev);

> > > > > +		if (ret)

> > > > > +			return ret;

> > > > > +

> > > > > +		part_data = dev_get_uclass_plat(dev);

> > > > > +		part_data->partnum = part;

> > > > > +		part_data->gpt_part_info = info;

> > > > > +		count++;

> > > > > +

> > > > > +		device_probe(dev);

> > > > > +	}

> > > > > +	debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > > > +

> > > > > +	return 0;

> > > > > +}

> > > > > +

> > > > >    static int blk_post_probe(struct udevice *dev)

> > > > >    {

> > > > >    	if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > > > @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > > >    	.post_probe	= blk_post_probe,

> > > > >    	.per_device_plat_auto	= sizeof(struct blk_desc),

> > > > >    };

> > > > > +

> > > > > +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > > > +			   lbaint_t blkcnt, void *buffer)

> > > > > +{

> > > > > +	struct udevice *parent;

> > > > > +	struct disk_part *part;

> > > > > +	const struct blk_ops *ops;

> > > > > +

> > > > > +	parent = dev_get_parent(dev);

> > > > 

> > > > What device type will the parent have if it is a eMMC hardware partition?

> > > > 

> > > > > +	ops = blk_get_ops(parent);

> > > > > +	if (!ops->read)

> > > > > +		return -ENOSYS;

> > > > > +

> > > > > +	part = dev_get_uclass_plat(dev);

> > > > 

> > > > You should check that we do not access the block device past the

> > > > partition end:

> > > 

> > > Yes, I will fix all of checks.

> > > 

> > > > struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > > 	return -EFAULT.

> > > > 

> > > > > +	start += part->gpt_part_info.start;

> > 

> > A better solution is:

> >          if (start >= part->gpt_part_info.size)

> >                  return 0;

> > 

> >          if ((start + blkcnt) > part->gpt_part_info.size)

> >                  blkcnt = part->gpt_part_info.size - start;

> >          start += part->gpt_part_info.start;

> > instead of returning -EFAULT.

> > (note that start and blkcnt are in "block".)

> 

> What is your motivation to support an illegal access?

> 

> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> ReadBlocks() and WriteBlocks() services must return

> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> valid.


I interpreted that 'LBA' was the third parameter to ReadBlocks API,
and that if the starting block is out of partition region, we should
return an error (and if not, we still want to trim IO request to fit
into partition size as other OS's API like linux does).
Do you think it's incorrect?

-Takahiro Akashi


> So we should return an error code here that can be translated

> into EFI_INVALID_PARAMETER.

> 

> Best regards

> 

> Heinrich

> 

> > 

> > -Takahiro Akashi

> > 

> > > > > +

> > > > > +	return ops->read(parent, start, blkcnt, buffer);

> > > > > +}

> > > > > +

> > > > > +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

> > > > > +			    lbaint_t blkcnt, const void *buffer)

> > > > > +{

> > > > > +	struct udevice *parent;

> > > > > +	struct disk_part *part;

> > > > > +	const struct blk_ops *ops;

> > > > > +

> > > > > +	parent = dev_get_parent(dev);

> > > > > +	ops = blk_get_ops(parent);

> > > > > +	if (!ops->write)

> > > > > +		return -ENOSYS;

> > > > > +

> > > > > +	part = dev_get_uclass_plat(dev);

> > > > > +	start += part->gpt_part_info.start;

> > > > 

> > > > here too

> > > > 

> > > > > +

> > > > > +	return ops->write(parent, start, blkcnt, buffer);

> > > > > +}

> > > > > +

> > > > > +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

> > > > > +			    lbaint_t blkcnt)

> > > > > +{

> > > > > +	struct udevice *parent;

> > > > > +	struct disk_part *part;

> > > > > +	const struct blk_ops *ops;

> > > > > +

> > > > > +	parent = dev_get_parent(dev);

> > > > > +	ops = blk_get_ops(parent);

> > > > > +	if (!ops->erase)

> > > > > +		return -ENOSYS;

> > > > > +

> > > > > +	part = dev_get_uclass_plat(dev);

> > > > > +	start += part->gpt_part_info.start;

> > > > 

> > > > here too

> > > > 

> > > > Best regards

> > > > 

> > > > Heinrich

> > > > 

> > > > > +

> > > > > +	return ops->erase(parent, start, blkcnt);

> > > > > +}

> > > > > +

> > > > > +static const struct blk_ops blk_part_ops = {

> > > > > +	.read	= blk_part_read,

> > > > > +	.write	= blk_part_write,

> > > > > +	.erase	= blk_part_erase,

> > > > > +};

> > > > > +

> > > > > +U_BOOT_DRIVER(blk_partition) = {

> > > > > +	.name		= "blk_partition",

> > > > > +	.id		= UCLASS_PARTITION,

> > > > > +	.ops		= &blk_part_ops,

> > > > > +};

> > > > > +

> > > > > +UCLASS_DRIVER(partition) = {

> > > > > +	.id		= UCLASS_PARTITION,

> > > > > +	.per_device_plat_auto	= sizeof(struct disk_part),

> > > > > +	.name		= "partition",

> > > > > +};

> > > > > diff --git a/include/blk.h b/include/blk.h

> > > > > index 19bab081c2cd..3d883eb1db64 100644

> > > > > --- a/include/blk.h

> > > > > +++ b/include/blk.h

> > > > > @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

> > > > >    		       const char *name, int if_type, int devnum, int blksz,

> > > > >    		       lbaint_t lba, struct udevice **devp);

> > > > > 

> > > > > +/**

> > > > > + * blk_create_partitions - Create block devices for disk partitions

> > > > > + *

> > > > > + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

> > > > > + *

> > > > > + * @parent:	Whole disk device

> > > > > + */

> > > > > +int blk_create_partitions(struct udevice *parent);

> > > > > +

> > > > >    /**

> > > > >     * blk_unbind_all() - Unbind all device of the given interface type

> > > > >     *

> > > > > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

> > > > > index e7edd409f307..30892d01ce13 100644

> > > > > --- a/include/dm/uclass-id.h

> > > > > +++ b/include/dm/uclass-id.h

> > > > > @@ -80,6 +80,7 @@ enum uclass_id {

> > > > >    	UCLASS_P2SB,		/* (x86) Primary-to-Sideband Bus */

> > > > >    	UCLASS_PANEL,		/* Display panel, such as an LCD */

> > > > >    	UCLASS_PANEL_BACKLIGHT,	/* Backlight controller for panel */

> > > > > +	UCLASS_PARTITION,	/* Logical disk partition device */

> > > > >    	UCLASS_PCH,		/* x86 platform controller hub */

> > > > >    	UCLASS_PCI,		/* PCI bus */

> > > > >    	UCLASS_PCI_EP,		/* PCI endpoint device */

> > > > >

Simon Glass Oct. 11, 2021, 2:54 p.m. UTC | #7

Hi Takahiro,

On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>

> Heinrich,

>

> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> >

> >

> > On 10/8/21 02:51, AKASHI Takahiro wrote:

> > > On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > > On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > > >

> > > > >

> > > > > On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > > > > UCLASS_PARTITION device will be created as a child node of

> > > > > > UCLASS_BLK device.

> > > > > >

> > > > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > > > > ---

> > > > > >    drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > > > >    include/blk.h              |   9 +++

> > > > > >    include/dm/uclass-id.h     |   1 +

> > > > > >    3 files changed, 121 insertions(+)

> > > > > >

> > > > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > > > > index 83682dcc181a..dd7f3c0fe31e 100644

> > > > > > --- a/drivers/block/blk-uclass.c

> > > > > > +++ b/drivers/block/blk-uclass.c

> > > > > > @@ -12,6 +12,7 @@

> > > > > >    #include <log.h>

> > > > > >    #include <malloc.h>

> > > > > >    #include <part.h>

> > > > > > +#include <string.h>

> > > > > >    #include <dm/device-internal.h>

> > > > > >    #include <dm/lists.h>

> > > > > >    #include <dm/uclass-internal.h>

> > > > > > @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > > > >       return 0;

> > > > > >    }

> > > > > >

> > > > > > +int blk_create_partitions(struct udevice *parent)

> > > > > > +{

> > > > > > +     int part, count;

> > > > > > +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > > +     struct disk_partition info;

> > > > > > +     struct disk_part *part_data;

> > > > > > +     char devname[32];

> > > > > > +     struct udevice *dev;

> > > > > > +     int ret;

> > > > > > +

> > > > > > +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > > > > +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > > > > +             return 0;

> > > > > > +

> > > > > > +     /* Add devices for each partition */

> > > > > > +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > > > > +             if (part_get_info(desc, part, &info))

> > > > > > +                     continue;

> > > > > > +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > > > > +                      part);

> > > > > > +

> > > > > > +             ret = device_bind_driver(parent, "blk_partition",

> > > > > > +                                      strdup(devname), &dev);

> > > > > > +             if (ret)

> > > > > > +                     return ret;

> > > > > > +

> > > > > > +             part_data = dev_get_uclass_plat(dev);

> > > > > > +             part_data->partnum = part;

> > > > > > +             part_data->gpt_part_info = info;

> > > > > > +             count++;

> > > > > > +

> > > > > > +             device_probe(dev);

> > > > > > +     }

> > > > > > +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > > > > +

> > > > > > +     return 0;

> > > > > > +}

> > > > > > +

> > > > > >    static int blk_post_probe(struct udevice *dev)

> > > > > >    {

> > > > > >       if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > > > > @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > > > >       .post_probe     = blk_post_probe,

> > > > > >       .per_device_plat_auto   = sizeof(struct blk_desc),

> > > > > >    };

> > > > > > +

> > > > > > +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > > > > +                        lbaint_t blkcnt, void *buffer)

> > > > > > +{

> > > > > > +     struct udevice *parent;

> > > > > > +     struct disk_part *part;

> > > > > > +     const struct blk_ops *ops;

> > > > > > +

> > > > > > +     parent = dev_get_parent(dev);

> > > > >

> > > > > What device type will the parent have if it is a eMMC hardware partition?

> > > > >

> > > > > > +     ops = blk_get_ops(parent);

> > > > > > +     if (!ops->read)

> > > > > > +             return -ENOSYS;

> > > > > > +

> > > > > > +     part = dev_get_uclass_plat(dev);

> > > > >

> > > > > You should check that we do not access the block device past the

> > > > > partition end:

> > > >

> > > > Yes, I will fix all of checks.

> > > >

> > > > > struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > > >         return -EFAULT.

> > > > >

> > > > > > +     start += part->gpt_part_info.start;

> > >

> > > A better solution is:

> > >          if (start >= part->gpt_part_info.size)

> > >                  return 0;

> > >

> > >          if ((start + blkcnt) > part->gpt_part_info.size)

> > >                  blkcnt = part->gpt_part_info.size - start;

> > >          start += part->gpt_part_info.start;

> > > instead of returning -EFAULT.

> > > (note that start and blkcnt are in "block".)

> >

> > What is your motivation to support an illegal access?

> >

> > We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > ReadBlocks() and WriteBlocks() services must return

> > EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > valid.

>

> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> and that if the starting block is out of partition region, we should

> return an error (and if not, we still want to trim IO request to fit

> into partition size as other OS's API like linux does).

> Do you think it's incorrect?


[..]

Related to this patch I think that the partition type should be really
be a child of the media device:

- MMC
    |- BLK
    |- PARTITION
       |- BLK
    |- PARTITION
       |- BLK
    |- PARTITION
       |- BLK

It seems more natural to me that putting the partitions under the
top-level BLK device, so that BLK remains a 'terminal' device.

The partition uclass is different from BLK, of course. It could
contain information about the partition such as its partition number
and UUID.

Regards,
Simon

Heinrich Schuchardt Oct. 11, 2021, 3:02 p.m. UTC | #8

On 10/11/21 16:54, Simon Glass wrote:
> Hi Takahiro,

>

> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> <takahiro.akashi@linaro.org> wrote:

>>

>> Heinrich,

>>

>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

>>>

>>>

>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

>>>>>>

>>>>>>

>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

>>>>>>> UCLASS_PARTITION device will be created as a child node of

>>>>>>> UCLASS_BLK device.

>>>>>>>

>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

>>>>>>> ---

>>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>>>>>>>     include/blk.h              |   9 +++

>>>>>>>     include/dm/uclass-id.h     |   1 +

>>>>>>>     3 files changed, 121 insertions(+)

>>>>>>>

>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

>>>>>>> --- a/drivers/block/blk-uclass.c

>>>>>>> +++ b/drivers/block/blk-uclass.c

>>>>>>> @@ -12,6 +12,7 @@

>>>>>>>     #include <log.h>

>>>>>>>     #include <malloc.h>

>>>>>>>     #include <part.h>

>>>>>>> +#include <string.h>

>>>>>>>     #include <dm/device-internal.h>

>>>>>>>     #include <dm/lists.h>

>>>>>>>     #include <dm/uclass-internal.h>

>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>>>>>>>        return 0;

>>>>>>>     }

>>>>>>>

>>>>>>> +int blk_create_partitions(struct udevice *parent)

>>>>>>> +{

>>>>>>> +     int part, count;

>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>>>>> +     struct disk_partition info;

>>>>>>> +     struct disk_part *part_data;

>>>>>>> +     char devname[32];

>>>>>>> +     struct udevice *dev;

>>>>>>> +     int ret;

>>>>>>> +

>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

>>>>>>> +             return 0;

>>>>>>> +

>>>>>>> +     /* Add devices for each partition */

>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

>>>>>>> +             if (part_get_info(desc, part, &info))

>>>>>>> +                     continue;

>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

>>>>>>> +                      part);

>>>>>>> +

>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

>>>>>>> +                                      strdup(devname), &dev);

>>>>>>> +             if (ret)

>>>>>>> +                     return ret;

>>>>>>> +

>>>>>>> +             part_data = dev_get_uclass_plat(dev);

>>>>>>> +             part_data->partnum = part;

>>>>>>> +             part_data->gpt_part_info = info;

>>>>>>> +             count++;

>>>>>>> +

>>>>>>> +             device_probe(dev);

>>>>>>> +     }

>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

>>>>>>> +

>>>>>>> +     return 0;

>>>>>>> +}

>>>>>>> +

>>>>>>>     static int blk_post_probe(struct udevice *dev)

>>>>>>>     {

>>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>>>>>>>        .post_probe     = blk_post_probe,

>>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

>>>>>>>     };

>>>>>>> +

>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

>>>>>>> +                        lbaint_t blkcnt, void *buffer)

>>>>>>> +{

>>>>>>> +     struct udevice *parent;

>>>>>>> +     struct disk_part *part;

>>>>>>> +     const struct blk_ops *ops;

>>>>>>> +

>>>>>>> +     parent = dev_get_parent(dev);

>>>>>>

>>>>>> What device type will the parent have if it is a eMMC hardware partition?

>>>>>>

>>>>>>> +     ops = blk_get_ops(parent);

>>>>>>> +     if (!ops->read)

>>>>>>> +             return -ENOSYS;

>>>>>>> +

>>>>>>> +     part = dev_get_uclass_plat(dev);

>>>>>>

>>>>>> You should check that we do not access the block device past the

>>>>>> partition end:

>>>>>

>>>>> Yes, I will fix all of checks.

>>>>>

>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

>>>>>>          return -EFAULT.

>>>>>>

>>>>>>> +     start += part->gpt_part_info.start;

>>>>

>>>> A better solution is:

>>>>           if (start >= part->gpt_part_info.size)

>>>>                   return 0;

>>>>

>>>>           if ((start + blkcnt) > part->gpt_part_info.size)

>>>>                   blkcnt = part->gpt_part_info.size - start;

>>>>           start += part->gpt_part_info.start;

>>>> instead of returning -EFAULT.

>>>> (note that start and blkcnt are in "block".)

>>>

>>> What is your motivation to support an illegal access?

>>>

>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

>>> ReadBlocks() and WriteBlocks() services must return

>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

>>> valid.

>>

>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

>> and that if the starting block is out of partition region, we should

>> return an error (and if not, we still want to trim IO request to fit

>> into partition size as other OS's API like linux does).

>> Do you think it's incorrect?

>

> [..]

>

> Related to this patch I think that the partition type should be really

> be a child of the media device:

>

> - MMC

>      |- BLK

>      |- PARTITION

>         |- BLK

>      |- PARTITION

>         |- BLK

>      |- PARTITION

>         |- BLK

>

> It seems more natural to me that putting the partitions under the

> top-level BLK device, so that BLK remains a 'terminal' device.

>

> The partition uclass is different from BLK, of course. It could

> contain information about the partition such as its partition number

> and UUID.


Do you mean hardware partition here? Otherwise I would not know what BLK
should model.

Best regards

Heinrich

Simon Glass Oct. 11, 2021, 4:14 p.m. UTC | #9

Hi Heinrich,

On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>

>

>

> On 10/11/21 16:54, Simon Glass wrote:

> > Hi Takahiro,

> >

> > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > <takahiro.akashi@linaro.org> wrote:

> >>

> >> Heinrich,

> >>

> >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> >>>

> >>>

> >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> >>>>>>

> >>>>>>

> >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> >>>>>>> UCLASS_PARTITION device will be created as a child node of

> >>>>>>> UCLASS_BLK device.

> >>>>>>>

> >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> >>>>>>> ---

> >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> >>>>>>>     include/blk.h              |   9 +++

> >>>>>>>     include/dm/uclass-id.h     |   1 +

> >>>>>>>     3 files changed, 121 insertions(+)

> >>>>>>>

> >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> >>>>>>> --- a/drivers/block/blk-uclass.c

> >>>>>>> +++ b/drivers/block/blk-uclass.c

> >>>>>>> @@ -12,6 +12,7 @@

> >>>>>>>     #include <log.h>

> >>>>>>>     #include <malloc.h>

> >>>>>>>     #include <part.h>

> >>>>>>> +#include <string.h>

> >>>>>>>     #include <dm/device-internal.h>

> >>>>>>>     #include <dm/lists.h>

> >>>>>>>     #include <dm/uclass-internal.h>

> >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> >>>>>>>        return 0;

> >>>>>>>     }

> >>>>>>>

> >>>>>>> +int blk_create_partitions(struct udevice *parent)

> >>>>>>> +{

> >>>>>>> +     int part, count;

> >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> >>>>>>> +     struct disk_partition info;

> >>>>>>> +     struct disk_part *part_data;

> >>>>>>> +     char devname[32];

> >>>>>>> +     struct udevice *dev;

> >>>>>>> +     int ret;

> >>>>>>> +

> >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> >>>>>>> +             return 0;

> >>>>>>> +

> >>>>>>> +     /* Add devices for each partition */

> >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> >>>>>>> +             if (part_get_info(desc, part, &info))

> >>>>>>> +                     continue;

> >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> >>>>>>> +                      part);

> >>>>>>> +

> >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> >>>>>>> +                                      strdup(devname), &dev);

> >>>>>>> +             if (ret)

> >>>>>>> +                     return ret;

> >>>>>>> +

> >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> >>>>>>> +             part_data->partnum = part;

> >>>>>>> +             part_data->gpt_part_info = info;

> >>>>>>> +             count++;

> >>>>>>> +

> >>>>>>> +             device_probe(dev);

> >>>>>>> +     }

> >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> >>>>>>> +

> >>>>>>> +     return 0;

> >>>>>>> +}

> >>>>>>> +

> >>>>>>>     static int blk_post_probe(struct udevice *dev)

> >>>>>>>     {

> >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> >>>>>>>        .post_probe     = blk_post_probe,

> >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> >>>>>>>     };

> >>>>>>> +

> >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> >>>>>>> +{

> >>>>>>> +     struct udevice *parent;

> >>>>>>> +     struct disk_part *part;

> >>>>>>> +     const struct blk_ops *ops;

> >>>>>>> +

> >>>>>>> +     parent = dev_get_parent(dev);

> >>>>>>

> >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> >>>>>>

> >>>>>>> +     ops = blk_get_ops(parent);

> >>>>>>> +     if (!ops->read)

> >>>>>>> +             return -ENOSYS;

> >>>>>>> +

> >>>>>>> +     part = dev_get_uclass_plat(dev);

> >>>>>>

> >>>>>> You should check that we do not access the block device past the

> >>>>>> partition end:

> >>>>>

> >>>>> Yes, I will fix all of checks.

> >>>>>

> >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> >>>>>>          return -EFAULT.

> >>>>>>

> >>>>>>> +     start += part->gpt_part_info.start;

> >>>>

> >>>> A better solution is:

> >>>>           if (start >= part->gpt_part_info.size)

> >>>>                   return 0;

> >>>>

> >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> >>>>                   blkcnt = part->gpt_part_info.size - start;

> >>>>           start += part->gpt_part_info.start;

> >>>> instead of returning -EFAULT.

> >>>> (note that start and blkcnt are in "block".)

> >>>

> >>> What is your motivation to support an illegal access?

> >>>

> >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> >>> ReadBlocks() and WriteBlocks() services must return

> >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> >>> valid.

> >>

> >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> >> and that if the starting block is out of partition region, we should

> >> return an error (and if not, we still want to trim IO request to fit

> >> into partition size as other OS's API like linux does).

> >> Do you think it's incorrect?

> >

> > [..]

> >

> > Related to this patch I think that the partition type should be really

> > be a child of the media device:

> >

> > - MMC

> >      |- BLK

> >      |- PARTITION

> >         |- BLK

> >      |- PARTITION

> >         |- BLK

> >      |- PARTITION

> >         |- BLK

> >

> > It seems more natural to me that putting the partitions under the

> > top-level BLK device, so that BLK remains a 'terminal' device.

> >

> > The partition uclass is different from BLK, of course. It could

> > contain information about the partition such as its partition number

> > and UUID.

>

> Do you mean hardware partition here? Otherwise I would not know what BLK

> should model.


I mean that (I think) we should not use BLK to model partitions. A BLK
should just be a block device.

I don't see any difference between a partition and a hardware
partition. We presumably end up with a hierarchy though. Do we need a
HWPARTITION uclass so we can handle the hardware partitions
differently?

Regards,
Simon

Heinrich Schuchardt Oct. 11, 2021, 4:48 p.m. UTC | #10

On 10/11/21 18:14, Simon Glass wrote:
> Hi Heinrich,

>

> On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

>>

>>

>>

>> On 10/11/21 16:54, Simon Glass wrote:

>>> Hi Takahiro,

>>>

>>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

>>> <takahiro.akashi@linaro.org> wrote:

>>>>

>>>> Heinrich,

>>>>

>>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

>>>>>

>>>>>

>>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

>>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

>>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

>>>>>>>>

>>>>>>>>

>>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

>>>>>>>>> UCLASS_PARTITION device will be created as a child node of

>>>>>>>>> UCLASS_BLK device.

>>>>>>>>>

>>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

>>>>>>>>> ---

>>>>>>>>>      drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>>>>>>>>>      include/blk.h              |   9 +++

>>>>>>>>>      include/dm/uclass-id.h     |   1 +

>>>>>>>>>      3 files changed, 121 insertions(+)

>>>>>>>>>

>>>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

>>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

>>>>>>>>> --- a/drivers/block/blk-uclass.c

>>>>>>>>> +++ b/drivers/block/blk-uclass.c

>>>>>>>>> @@ -12,6 +12,7 @@

>>>>>>>>>      #include <log.h>

>>>>>>>>>      #include <malloc.h>

>>>>>>>>>      #include <part.h>

>>>>>>>>> +#include <string.h>

>>>>>>>>>      #include <dm/device-internal.h>

>>>>>>>>>      #include <dm/lists.h>

>>>>>>>>>      #include <dm/uclass-internal.h>

>>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>>>>>>>>>         return 0;

>>>>>>>>>      }

>>>>>>>>>

>>>>>>>>> +int blk_create_partitions(struct udevice *parent)

>>>>>>>>> +{

>>>>>>>>> +     int part, count;

>>>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>>>>>>> +     struct disk_partition info;

>>>>>>>>> +     struct disk_part *part_data;

>>>>>>>>> +     char devname[32];

>>>>>>>>> +     struct udevice *dev;

>>>>>>>>> +     int ret;

>>>>>>>>> +

>>>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

>>>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

>>>>>>>>> +             return 0;

>>>>>>>>> +

>>>>>>>>> +     /* Add devices for each partition */

>>>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

>>>>>>>>> +             if (part_get_info(desc, part, &info))

>>>>>>>>> +                     continue;

>>>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

>>>>>>>>> +                      part);

>>>>>>>>> +

>>>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

>>>>>>>>> +                                      strdup(devname), &dev);

>>>>>>>>> +             if (ret)

>>>>>>>>> +                     return ret;

>>>>>>>>> +

>>>>>>>>> +             part_data = dev_get_uclass_plat(dev);

>>>>>>>>> +             part_data->partnum = part;

>>>>>>>>> +             part_data->gpt_part_info = info;

>>>>>>>>> +             count++;

>>>>>>>>> +

>>>>>>>>> +             device_probe(dev);

>>>>>>>>> +     }

>>>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

>>>>>>>>> +

>>>>>>>>> +     return 0;

>>>>>>>>> +}

>>>>>>>>> +

>>>>>>>>>      static int blk_post_probe(struct udevice *dev)

>>>>>>>>>      {

>>>>>>>>>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

>>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>>>>>>>>>         .post_probe     = blk_post_probe,

>>>>>>>>>         .per_device_plat_auto   = sizeof(struct blk_desc),

>>>>>>>>>      };

>>>>>>>>> +

>>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

>>>>>>>>> +                        lbaint_t blkcnt, void *buffer)

>>>>>>>>> +{

>>>>>>>>> +     struct udevice *parent;

>>>>>>>>> +     struct disk_part *part;

>>>>>>>>> +     const struct blk_ops *ops;

>>>>>>>>> +

>>>>>>>>> +     parent = dev_get_parent(dev);

>>>>>>>>

>>>>>>>> What device type will the parent have if it is a eMMC hardware partition?

>>>>>>>>

>>>>>>>>> +     ops = blk_get_ops(parent);

>>>>>>>>> +     if (!ops->read)

>>>>>>>>> +             return -ENOSYS;

>>>>>>>>> +

>>>>>>>>> +     part = dev_get_uclass_plat(dev);

>>>>>>>>

>>>>>>>> You should check that we do not access the block device past the

>>>>>>>> partition end:

>>>>>>>

>>>>>>> Yes, I will fix all of checks.

>>>>>>>

>>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

>>>>>>>>           return -EFAULT.

>>>>>>>>

>>>>>>>>> +     start += part->gpt_part_info.start;

>>>>>>

>>>>>> A better solution is:

>>>>>>            if (start >= part->gpt_part_info.size)

>>>>>>                    return 0;

>>>>>>

>>>>>>            if ((start + blkcnt) > part->gpt_part_info.size)

>>>>>>                    blkcnt = part->gpt_part_info.size - start;

>>>>>>            start += part->gpt_part_info.start;

>>>>>> instead of returning -EFAULT.

>>>>>> (note that start and blkcnt are in "block".)

>>>>>

>>>>> What is your motivation to support an illegal access?

>>>>>

>>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

>>>>> ReadBlocks() and WriteBlocks() services must return

>>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

>>>>> valid.

>>>>

>>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

>>>> and that if the starting block is out of partition region, we should

>>>> return an error (and if not, we still want to trim IO request to fit

>>>> into partition size as other OS's API like linux does).

>>>> Do you think it's incorrect?

>>>

>>> [..]

>>>

>>> Related to this patch I think that the partition type should be really

>>> be a child of the media device:

>>>

>>> - MMC

>>>       |- BLK

>>>       |- PARTITION

>>>          |- BLK

>>>       |- PARTITION

>>>          |- BLK

>>>       |- PARTITION

>>>          |- BLK

>>>

>>> It seems more natural to me that putting the partitions under the

>>> top-level BLK device, so that BLK remains a 'terminal' device.

>>>

>>> The partition uclass is different from BLK, of course. It could

>>> contain information about the partition such as its partition number

>>> and UUID.

>>

>> Do you mean hardware partition here? Otherwise I would not know what BLK

>> should model.

>

> I mean that (I think) we should not use BLK to model partitions. A BLK

> should just be a block device.


That is fine. But this implies that a software partition is the child of
a block partition and not the other way round. So the tree should like:

MMC
|- BLK (user hardware partition)
||- PARTITION 1 (software partition)
||- PARTITION 2 (software partition)
|...
||- PARTITION n (software partition)
|- BLK (rpmb hardware partition)
|- BLK (boot0 hardware partition)
|- BLK (boot1 hardware partition)

>

> I don't see any difference between a partition and a hardware

> partition. We presumably end up with a hierarchy though. Do we need a

> HWPARTITION uclass so we can handle the hardware partitions

> differently?


Software partitions are defined and discovered via partition tables.
Hardware partitions are defined in a hardware specific way.

All software partitions map to HD() device tree nodes in UEFI.
An MMC device maps to an eMMC() node
MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should
do the same in U-Boot.
An SD-card maps to an SD() node.
An NVMe namespace maps to a NVMe() node.
An SCSI LUN maps to a Scsi() node.
SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

The simple file protocol is only provided by HD() nodes and not by nodes
representing hardware partitions. If the whole hardware partition is
formatted as a file system you would still create a HD() node with
partition number 0.

Best regards

Heinrich

Simon Glass Oct. 11, 2021, 5:41 p.m. UTC | #11

Hi Heinrich,,

On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>

>

>

> On 10/11/21 18:14, Simon Glass wrote:

> > Hi Heinrich,

> >

> > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >>

> >>

> >>

> >> On 10/11/21 16:54, Simon Glass wrote:

> >>> Hi Takahiro,

> >>>

> >>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> >>> <takahiro.akashi@linaro.org> wrote:

> >>>>

> >>>> Heinrich,

> >>>>

> >>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> >>>>>

> >>>>>

> >>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> >>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> >>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> >>>>>>>>

> >>>>>>>>

> >>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> >>>>>>>>> UCLASS_PARTITION device will be created as a child node of

> >>>>>>>>> UCLASS_BLK device.

> >>>>>>>>>

> >>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> >>>>>>>>> ---

> >>>>>>>>>      drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> >>>>>>>>>      include/blk.h              |   9 +++

> >>>>>>>>>      include/dm/uclass-id.h     |   1 +

> >>>>>>>>>      3 files changed, 121 insertions(+)

> >>>>>>>>>

> >>>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> >>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> >>>>>>>>> --- a/drivers/block/blk-uclass.c

> >>>>>>>>> +++ b/drivers/block/blk-uclass.c

> >>>>>>>>> @@ -12,6 +12,7 @@

> >>>>>>>>>      #include <log.h>

> >>>>>>>>>      #include <malloc.h>

> >>>>>>>>>      #include <part.h>

> >>>>>>>>> +#include <string.h>

> >>>>>>>>>      #include <dm/device-internal.h>

> >>>>>>>>>      #include <dm/lists.h>

> >>>>>>>>>      #include <dm/uclass-internal.h>

> >>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> >>>>>>>>>         return 0;

> >>>>>>>>>      }

> >>>>>>>>>

> >>>>>>>>> +int blk_create_partitions(struct udevice *parent)

> >>>>>>>>> +{

> >>>>>>>>> +     int part, count;

> >>>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> >>>>>>>>> +     struct disk_partition info;

> >>>>>>>>> +     struct disk_part *part_data;

> >>>>>>>>> +     char devname[32];

> >>>>>>>>> +     struct udevice *dev;

> >>>>>>>>> +     int ret;

> >>>>>>>>> +

> >>>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> >>>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> >>>>>>>>> +             return 0;

> >>>>>>>>> +

> >>>>>>>>> +     /* Add devices for each partition */

> >>>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> >>>>>>>>> +             if (part_get_info(desc, part, &info))

> >>>>>>>>> +                     continue;

> >>>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> >>>>>>>>> +                      part);

> >>>>>>>>> +

> >>>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> >>>>>>>>> +                                      strdup(devname), &dev);

> >>>>>>>>> +             if (ret)

> >>>>>>>>> +                     return ret;

> >>>>>>>>> +

> >>>>>>>>> +             part_data = dev_get_uclass_plat(dev);

> >>>>>>>>> +             part_data->partnum = part;

> >>>>>>>>> +             part_data->gpt_part_info = info;

> >>>>>>>>> +             count++;

> >>>>>>>>> +

> >>>>>>>>> +             device_probe(dev);

> >>>>>>>>> +     }

> >>>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> >>>>>>>>> +

> >>>>>>>>> +     return 0;

> >>>>>>>>> +}

> >>>>>>>>> +

> >>>>>>>>>      static int blk_post_probe(struct udevice *dev)

> >>>>>>>>>      {

> >>>>>>>>>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

> >>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> >>>>>>>>>         .post_probe     = blk_post_probe,

> >>>>>>>>>         .per_device_plat_auto   = sizeof(struct blk_desc),

> >>>>>>>>>      };

> >>>>>>>>> +

> >>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> >>>>>>>>> +                        lbaint_t blkcnt, void *buffer)

> >>>>>>>>> +{

> >>>>>>>>> +     struct udevice *parent;

> >>>>>>>>> +     struct disk_part *part;

> >>>>>>>>> +     const struct blk_ops *ops;

> >>>>>>>>> +

> >>>>>>>>> +     parent = dev_get_parent(dev);

> >>>>>>>>

> >>>>>>>> What device type will the parent have if it is a eMMC hardware partition?

> >>>>>>>>

> >>>>>>>>> +     ops = blk_get_ops(parent);

> >>>>>>>>> +     if (!ops->read)

> >>>>>>>>> +             return -ENOSYS;

> >>>>>>>>> +

> >>>>>>>>> +     part = dev_get_uclass_plat(dev);

> >>>>>>>>

> >>>>>>>> You should check that we do not access the block device past the

> >>>>>>>> partition end:

> >>>>>>>

> >>>>>>> Yes, I will fix all of checks.

> >>>>>>>

> >>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> >>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> >>>>>>>>           return -EFAULT.

> >>>>>>>>

> >>>>>>>>> +     start += part->gpt_part_info.start;

> >>>>>>

> >>>>>> A better solution is:

> >>>>>>            if (start >= part->gpt_part_info.size)

> >>>>>>                    return 0;

> >>>>>>

> >>>>>>            if ((start + blkcnt) > part->gpt_part_info.size)

> >>>>>>                    blkcnt = part->gpt_part_info.size - start;

> >>>>>>            start += part->gpt_part_info.start;

> >>>>>> instead of returning -EFAULT.

> >>>>>> (note that start and blkcnt are in "block".)

> >>>>>

> >>>>> What is your motivation to support an illegal access?

> >>>>>

> >>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> >>>>> ReadBlocks() and WriteBlocks() services must return

> >>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> >>>>> valid.

> >>>>

> >>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> >>>> and that if the starting block is out of partition region, we should

> >>>> return an error (and if not, we still want to trim IO request to fit

> >>>> into partition size as other OS's API like linux does).

> >>>> Do you think it's incorrect?

> >>>

> >>> [..]

> >>>

> >>> Related to this patch I think that the partition type should be really

> >>> be a child of the media device:

> >>>

> >>> - MMC

> >>>       |- BLK

> >>>       |- PARTITION

> >>>          |- BLK

> >>>       |- PARTITION

> >>>          |- BLK

> >>>       |- PARTITION

> >>>          |- BLK

> >>>

> >>> It seems more natural to me that putting the partitions under the

> >>> top-level BLK device, so that BLK remains a 'terminal' device.

> >>>

> >>> The partition uclass is different from BLK, of course. It could

> >>> contain information about the partition such as its partition number

> >>> and UUID.

> >>

> >> Do you mean hardware partition here? Otherwise I would not know what BLK

> >> should model.

> >

> > I mean that (I think) we should not use BLK to model partitions. A BLK

> > should just be a block device.

>

> That is fine. But this implies that a software partition is the child of

> a block partition and not the other way round. So the tree should like:

>

> MMC

> |- BLK (user hardware partition)

> ||- PARTITION 1 (software partition)

> ||- PARTITION 2 (software partition)

> |...

> ||- PARTITION n (software partition)

> |- BLK (rpmb hardware partition)

> |- BLK (boot0 hardware partition)

> |- BLK (boot1 hardware partition)


I presume you meant to include a BLK device under each PARTITION?

But anyway, I was more thinking of this:

MMC
| HWPARTITION rpmb
|| BLK whole rpmb
|| PARTITION 1
||| BLK
|| PARTITION 2
||| BLK
|| PARTITION 3
||| BLK
| HWPARTITION boot0
|| BLK
(maybe have PARTITION in here too?
| HWPARTITION boot1
(maybe have PARTITION in here too?
|| BLK

>

> >

> > I don't see any difference between a partition and a hardware

> > partition. We presumably end up with a hierarchy though. Do we need a

> > HWPARTITION uclass so we can handle the hardware partitions

> > differently?

>

> Software partitions are defined and discovered via partition tables.

> Hardware partitions are defined in a hardware specific way.

>

> All software partitions map to HD() device tree nodes in UEFI.

> An MMC device maps to an eMMC() node

> MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

> do the same in U-Boot.

> An SD-card maps to an SD() node.

> An NVMe namespace maps to a NVMe() node.

> An SCSI LUN maps to a Scsi() node.

> SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.


I'm not quite sure about the terminology here. I'm not even talking
about UEFI, really, just how best to model this stuff in U-Boot.

In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,
right? I'm a little worried it is not modelled correctly. After all,
what is the parent of a SCSI device?

>

> The simple file protocol is only provided by HD() nodes and not by nodes

> representing hardware partitions. If the whole hardware partition is

> formatted as a file system you would still create a HD() node with

> partition number 0.


Regards,
Simon

AKASHI Takahiro Oct. 12, 2021, 3:53 a.m. UTC | #12

Simon,

On Sun, Oct 10, 2021 at 08:14:34AM -0600, Simon Glass wrote:
> Hi Takahiro,

> 

> On Thu, 30 Sept 2021 at 23:03, AKASHI Takahiro

> <takahiro.akashi@linaro.org> wrote:

> >

> > UCLASS_PARTITION device will be created as a child node of

> > UCLASS_BLK device.

> >

> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > ---

> >  drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> >  include/blk.h              |   9 +++

> >  include/dm/uclass-id.h     |   1 +

> >  3 files changed, 121 insertions(+)

> >

> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > index 83682dcc181a..dd7f3c0fe31e 100644

> > --- a/drivers/block/blk-uclass.c

> > +++ b/drivers/block/blk-uclass.c

> > @@ -12,6 +12,7 @@

> >  #include <log.h>

> >  #include <malloc.h>

> >  #include <part.h>

> > +#include <string.h>

> >  #include <dm/device-internal.h>

> >  #include <dm/lists.h>

> >  #include <dm/uclass-internal.h>

> > @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> >         return 0;

> >  }

> >

> > +int blk_create_partitions(struct udevice *parent)

> > +{

> > +       int part, count;

> > +       struct blk_desc *desc = dev_get_uclass_plat(parent);

> > +       struct disk_partition info;

> > +       struct disk_part *part_data;

> > +       char devname[32];

> > +       struct udevice *dev;

> > +       int ret;

> > +

> > +       if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > +           !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > +               return 0;

> > +

> > +       /* Add devices for each partition */

> > +       for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > +               if (part_get_info(desc, part, &info))

> > +                       continue;

> > +               snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > +                        part);

> > +

> > +               ret = device_bind_driver(parent, "blk_partition",

> > +                                        strdup(devname), &dev);

> > +               if (ret)

> > +                       return ret;

> > +

> > +               part_data = dev_get_uclass_plat(dev);

> > +               part_data->partnum = part;

> > +               part_data->gpt_part_info = info;

> > +               count++;

> > +

> > +               device_probe(dev);

> > +       }

> > +       debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> 

> log_debug() and drop __func__


OK.

> > +

> > +       return 0;

> > +}

> > +

> >  static int blk_post_probe(struct udevice *dev)

> >  {

> >         if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> >         .post_probe     = blk_post_probe,

> >         .per_device_plat_auto   = sizeof(struct blk_desc),

> >  };

> > +

> > +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > +                          lbaint_t blkcnt, void *buffer)

> > +{

> 

> part_blk_read() so that it is clear that this takes a UCLASS_PARTITION

> device, not a UCLASS_BLK


OK.

> > +       struct udevice *parent;

> > +       struct disk_part *part;

> > +       const struct blk_ops *ops;

> > +

> > +       parent = dev_get_parent(dev);

> > +       ops = blk_get_ops(parent);

> > +       if (!ops->read)

> > +               return -ENOSYS;

> > +

> > +       part = dev_get_uclass_plat(dev);

> > +       start += part->gpt_part_info.start;

> > +

> > +       return ops->read(parent, start, blkcnt, buffer);

> > +}

> > +

> > +static ulong blk_part_write(struct udevice *dev, lbaint_t start,

> > +                           lbaint_t blkcnt, const void *buffer)

> > +{

> > +       struct udevice *parent;

> > +       struct disk_part *part;

> > +       const struct blk_ops *ops;

> > +

> > +       parent = dev_get_parent(dev);

> > +       ops = blk_get_ops(parent);

> > +       if (!ops->write)

> > +               return -ENOSYS;

> > +

> > +       part = dev_get_uclass_plat(dev);

> > +       start += part->gpt_part_info.start;

> > +

> > +       return ops->write(parent, start, blkcnt, buffer);

> > +}

> > +

> > +static ulong blk_part_erase(struct udevice *dev, lbaint_t start,

> > +                           lbaint_t blkcnt)

> > +{

> > +       struct udevice *parent;

> > +       struct disk_part *part;

> > +       const struct blk_ops *ops;

> > +

> > +       parent = dev_get_parent(dev);

> > +       ops = blk_get_ops(parent);

> > +       if (!ops->erase)

> > +               return -ENOSYS;

> > +

> > +       part = dev_get_uclass_plat(dev);

> > +       start += part->gpt_part_info.start;

> > +

> > +       return ops->erase(parent, start, blkcnt);

> > +}

> > +

> > +static const struct blk_ops blk_part_ops = {

> > +       .read   = blk_part_read,

> > +       .write  = blk_part_write,

> > +       .erase  = blk_part_erase,

> > +};

> > +

> > +U_BOOT_DRIVER(blk_partition) = {

> > +       .name           = "blk_partition",

> > +       .id             = UCLASS_PARTITION,

> > +       .ops            = &blk_part_ops,

> > +};

> 

> Can you put this all in a separate part-uclass.c file? This too:


OK.
Then put the file under disk/,  driver/block or driver/partition?

> > +

> > +UCLASS_DRIVER(partition) = {

> > +       .id             = UCLASS_PARTITION,

> > +       .per_device_plat_auto   = sizeof(struct disk_part),

> > +       .name           = "partition",

> > +};

> > diff --git a/include/blk.h b/include/blk.h

> > index 19bab081c2cd..3d883eb1db64 100644

> > --- a/include/blk.h

> > +++ b/include/blk.h

> > @@ -366,6 +366,15 @@ int blk_create_devicef(struct udevice *parent, const char *drv_name,

> >                        const char *name, int if_type, int devnum, int blksz,

> >                        lbaint_t lba, struct udevice **devp);

> >

> > +/**

> > + * blk_create_partitions - Create block devices for disk partitions

> > + *

> > + * Create UCLASS_PARTITION udevices for each of disk partitions in @parent

> > + *

> > + * @parent:    Whole disk device

> 

> UCLASS_BLK?

> 

> It is good to document the device types to avoid people getting confused later.


OK.

> > + */

> > +int blk_create_partitions(struct udevice *parent);

> > +

> >  /**

> >   * blk_unbind_all() - Unbind all device of the given interface type

> >   *

> > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h

> > index e7edd409f307..30892d01ce13 100644

> > --- a/include/dm/uclass-id.h

> > +++ b/include/dm/uclass-id.h

> > @@ -80,6 +80,7 @@ enum uclass_id {

> >         UCLASS_P2SB,            /* (x86) Primary-to-Sideband Bus */

> >         UCLASS_PANEL,           /* Display panel, such as an LCD */

> >         UCLASS_PANEL_BACKLIGHT, /* Backlight controller for panel */

> > +       UCLASS_PARTITION,       /* Logical disk partition device */

> >         UCLASS_PCH,             /* x86 platform controller hub */

> >         UCLASS_PCI,             /* PCI bus */

> >         UCLASS_PCI_EP,          /* PCI endpoint device */

> > --

> > 2.33.0

> >

> 

> This is a new uclass so needs a sandbox test.


Yes, I intend to do so with pytest once we have some consensus
on interfaces.

-Takahiro Akashi


> Regards,

> Simon

AKASHI Takahiro Oct. 12, 2021, 5:12 a.m. UTC | #13

Simon, Heinrich,

On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:
> Hi Heinrich,,

> 

> On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >

> >

> >

> > On 10/11/21 18:14, Simon Glass wrote:

> > > Hi Heinrich,

> > >

> > > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > >>

> > >>

> > >>

> > >> On 10/11/21 16:54, Simon Glass wrote:

> > >>> Hi Takahiro,

> > >>>

> > >>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > >>> <takahiro.akashi@linaro.org> wrote:

> > >>>>

> > >>>> Heinrich,

> > >>>>

> > >>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > >>>>>

> > >>>>>

> > >>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > >>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > >>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > >>>>>>>>

> > >>>>>>>>

> > >>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > >>>>>>>>> UCLASS_PARTITION device will be created as a child node of

> > >>>>>>>>> UCLASS_BLK device.

> > >>>>>>>>>

> > >>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > >>>>>>>>> ---

> > >>>>>>>>>      drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > >>>>>>>>>      include/blk.h              |   9 +++

> > >>>>>>>>>      include/dm/uclass-id.h     |   1 +

> > >>>>>>>>>      3 files changed, 121 insertions(+)

> > >>>>>>>>>

> > >>>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > >>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > >>>>>>>>> --- a/drivers/block/blk-uclass.c

> > >>>>>>>>> +++ b/drivers/block/blk-uclass.c

> > >>>>>>>>> @@ -12,6 +12,7 @@

> > >>>>>>>>>      #include <log.h>

> > >>>>>>>>>      #include <malloc.h>

> > >>>>>>>>>      #include <part.h>

> > >>>>>>>>> +#include <string.h>

> > >>>>>>>>>      #include <dm/device-internal.h>

> > >>>>>>>>>      #include <dm/lists.h>

> > >>>>>>>>>      #include <dm/uclass-internal.h>

> > >>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > >>>>>>>>>         return 0;

> > >>>>>>>>>      }

> > >>>>>>>>>

> > >>>>>>>>> +int blk_create_partitions(struct udevice *parent)

> > >>>>>>>>> +{

> > >>>>>>>>> +     int part, count;

> > >>>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > >>>>>>>>> +     struct disk_partition info;

> > >>>>>>>>> +     struct disk_part *part_data;

> > >>>>>>>>> +     char devname[32];

> > >>>>>>>>> +     struct udevice *dev;

> > >>>>>>>>> +     int ret;

> > >>>>>>>>> +

> > >>>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > >>>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > >>>>>>>>> +             return 0;

> > >>>>>>>>> +

> > >>>>>>>>> +     /* Add devices for each partition */

> > >>>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > >>>>>>>>> +             if (part_get_info(desc, part, &info))

> > >>>>>>>>> +                     continue;

> > >>>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > >>>>>>>>> +                      part);

> > >>>>>>>>> +

> > >>>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > >>>>>>>>> +                                      strdup(devname), &dev);

> > >>>>>>>>> +             if (ret)

> > >>>>>>>>> +                     return ret;

> > >>>>>>>>> +

> > >>>>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > >>>>>>>>> +             part_data->partnum = part;

> > >>>>>>>>> +             part_data->gpt_part_info = info;

> > >>>>>>>>> +             count++;

> > >>>>>>>>> +

> > >>>>>>>>> +             device_probe(dev);

> > >>>>>>>>> +     }

> > >>>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > >>>>>>>>> +

> > >>>>>>>>> +     return 0;

> > >>>>>>>>> +}

> > >>>>>>>>> +

> > >>>>>>>>>      static int blk_post_probe(struct udevice *dev)

> > >>>>>>>>>      {

> > >>>>>>>>>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > >>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > >>>>>>>>>         .post_probe     = blk_post_probe,

> > >>>>>>>>>         .per_device_plat_auto   = sizeof(struct blk_desc),

> > >>>>>>>>>      };

> > >>>>>>>>> +

> > >>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > >>>>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > >>>>>>>>> +{

> > >>>>>>>>> +     struct udevice *parent;

> > >>>>>>>>> +     struct disk_part *part;

> > >>>>>>>>> +     const struct blk_ops *ops;

> > >>>>>>>>> +

> > >>>>>>>>> +     parent = dev_get_parent(dev);

> > >>>>>>>>

> > >>>>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > >>>>>>>>

> > >>>>>>>>> +     ops = blk_get_ops(parent);

> > >>>>>>>>> +     if (!ops->read)

> > >>>>>>>>> +             return -ENOSYS;

> > >>>>>>>>> +

> > >>>>>>>>> +     part = dev_get_uclass_plat(dev);

> > >>>>>>>>

> > >>>>>>>> You should check that we do not access the block device past the

> > >>>>>>>> partition end:

> > >>>>>>>

> > >>>>>>> Yes, I will fix all of checks.

> > >>>>>>>

> > >>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > >>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > >>>>>>>>           return -EFAULT.

> > >>>>>>>>

> > >>>>>>>>> +     start += part->gpt_part_info.start;

> > >>>>>>

> > >>>>>> A better solution is:

> > >>>>>>            if (start >= part->gpt_part_info.size)

> > >>>>>>                    return 0;

> > >>>>>>

> > >>>>>>            if ((start + blkcnt) > part->gpt_part_info.size)

> > >>>>>>                    blkcnt = part->gpt_part_info.size - start;

> > >>>>>>            start += part->gpt_part_info.start;

> > >>>>>> instead of returning -EFAULT.

> > >>>>>> (note that start and blkcnt are in "block".)

> > >>>>>

> > >>>>> What is your motivation to support an illegal access?

> > >>>>>

> > >>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > >>>>> ReadBlocks() and WriteBlocks() services must return

> > >>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > >>>>> valid.

> > >>>>

> > >>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > >>>> and that if the starting block is out of partition region, we should

> > >>>> return an error (and if not, we still want to trim IO request to fit

> > >>>> into partition size as other OS's API like linux does).

> > >>>> Do you think it's incorrect?

> > >>>

> > >>> [..]

> > >>>

> > >>> Related to this patch I think that the partition type should be really

> > >>> be a child of the media device:

> > >>>

> > >>> - MMC

> > >>>       |- BLK

> > >>>       |- PARTITION

> > >>>          |- BLK

> > >>>       |- PARTITION

> > >>>          |- BLK

> > >>>       |- PARTITION

> > >>>          |- BLK

> > >>>

> > >>> It seems more natural to me that putting the partitions under the

> > >>> top-level BLK device, so that BLK remains a 'terminal' device.

> > >>>

> > >>> The partition uclass is different from BLK, of course. It could

> > >>> contain information about the partition such as its partition number

> > >>> and UUID.

> > >>

> > >> Do you mean hardware partition here? Otherwise I would not know what BLK

> > >> should model.

> > >

> > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > should just be a block device.

> >

> > That is fine. But this implies that a software partition is the child of

> > a block partition and not the other way round. So the tree should like:

> >

> > MMC

> > |- BLK (user hardware partition)

> > ||- PARTITION 1 (software partition)

> > ||- PARTITION 2 (software partition)

> > |...

> > ||- PARTITION n (software partition)

> > |- BLK (rpmb hardware partition)

> > |- BLK (boot0 hardware partition)

> > |- BLK (boot1 hardware partition)

> 

> I presume you meant to include a BLK device under each PARTITION?


I do understand that PARTITION is not BLK, but thinking that there is always
one-to-one link between a PARTITION device and a BLK device, what benefit
will we see in distinguishing one from the other?
I'm afraid that this makes things a bit complicated.

> But anyway, I was more thinking of this:

> 

> MMC

> | HWPARTITION rpmb

> || BLK whole rpmb

> || PARTITION 1

> ||| BLK

> || PARTITION 2

> ||| BLK

> || PARTITION 3

> ||| BLK

> | HWPARTITION boot0

> || BLK

> (maybe have PARTITION in here too?

> | HWPARTITION boot1

> (maybe have PARTITION in here too?

> || BLK


I simply wonder why not we see "HWPARTITION" as yet another block device
[controller] (like scsi LUN's and/or NVME namespaces as discussed in
a thread of "part: call part_init() in blk_get_device_by_str() only for
MMC"?).

> >

> > >

> > > I don't see any difference between a partition and a hardware

> > > partition. We presumably end up with a hierarchy though. Do we need a

> > > HWPARTITION uclass so we can handle the hardware partitions

> > > differently?

> >

> > Software partitions are defined and discovered via partition tables.

> > Hardware partitions are defined in a hardware specific way.

> >

> > All software partitions map to HD() device tree nodes in UEFI.

> > An MMC device maps to an eMMC() node

> > MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

> > do the same in U-Boot.

> > An SD-card maps to an SD() node.

> > An NVMe namespace maps to a NVMe() node.

> > An SCSI LUN maps to a Scsi() node.

> > SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

> 

> I'm not quite sure about the terminology here. I'm not even talking

> about UEFI, really, just how best to model this stuff in U-Boot.


Anyhow, if we pursue the direction that you suggested here,
we will end up with having one PARTITION *driver* per partition type,
efi, dos or iso, under disk/?

# Oops, extra work :)

Thanks,
-Takahiro Akashi


> In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

> right? I'm a little worried it is not modelled correctly. After all,

> what is the parent of a SCSI device?

> 

> >

> > The simple file protocol is only provided by HD() nodes and not by nodes

> > representing hardware partitions. If the whole hardware partition is

> > formatted as a file system you would still create a HD() node with

> > partition number 0.

> 

> Regards,

> Simon

Heinrich Schuchardt Oct. 12, 2021, 6:42 a.m. UTC | #14

Am 12. Oktober 2021 07:12:59 MESZ schrieb AKASHI Takahiro <takahiro.akashi@linaro.org>:
>Simon, Heinrich,

>

>On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:

>> Hi Heinrich,,

>> 

>> On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

>> >

>> >

>> >

>> > On 10/11/21 18:14, Simon Glass wrote:

>> > > Hi Heinrich,

>> > >

>> > > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

>> > >>

>> > >>

>> > >>

>> > >> On 10/11/21 16:54, Simon Glass wrote:

>> > >>> Hi Takahiro,

>> > >>>

>> > >>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

>> > >>> <takahiro.akashi@linaro.org> wrote:

>> > >>>>

>> > >>>> Heinrich,

>> > >>>>

>> > >>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

>> > >>>>>

>> > >>>>>

>> > >>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

>> > >>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

>> > >>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

>> > >>>>>>>>

>> > >>>>>>>>

>> > >>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

>> > >>>>>>>>> UCLASS_PARTITION device will be created as a child node of

>> > >>>>>>>>> UCLASS_BLK device.

>> > >>>>>>>>>

>> > >>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

>> > >>>>>>>>> ---

>> > >>>>>>>>>      drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>> > >>>>>>>>>      include/blk.h              |   9 +++

>> > >>>>>>>>>      include/dm/uclass-id.h     |   1 +

>> > >>>>>>>>>      3 files changed, 121 insertions(+)

>> > >>>>>>>>>

>> > >>>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

>> > >>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

>> > >>>>>>>>> --- a/drivers/block/blk-uclass.c

>> > >>>>>>>>> +++ b/drivers/block/blk-uclass.c

>> > >>>>>>>>> @@ -12,6 +12,7 @@

>> > >>>>>>>>>      #include <log.h>

>> > >>>>>>>>>      #include <malloc.h>

>> > >>>>>>>>>      #include <part.h>

>> > >>>>>>>>> +#include <string.h>

>> > >>>>>>>>>      #include <dm/device-internal.h>

>> > >>>>>>>>>      #include <dm/lists.h>

>> > >>>>>>>>>      #include <dm/uclass-internal.h>

>> > >>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>> > >>>>>>>>>         return 0;

>> > >>>>>>>>>      }

>> > >>>>>>>>>

>> > >>>>>>>>> +int blk_create_partitions(struct udevice *parent)

>> > >>>>>>>>> +{

>> > >>>>>>>>> +     int part, count;

>> > >>>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

>> > >>>>>>>>> +     struct disk_partition info;

>> > >>>>>>>>> +     struct disk_part *part_data;

>> > >>>>>>>>> +     char devname[32];

>> > >>>>>>>>> +     struct udevice *dev;

>> > >>>>>>>>> +     int ret;

>> > >>>>>>>>> +

>> > >>>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

>> > >>>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

>> > >>>>>>>>> +             return 0;

>> > >>>>>>>>> +

>> > >>>>>>>>> +     /* Add devices for each partition */

>> > >>>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

>> > >>>>>>>>> +             if (part_get_info(desc, part, &info))

>> > >>>>>>>>> +                     continue;

>> > >>>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

>> > >>>>>>>>> +                      part);

>> > >>>>>>>>> +

>> > >>>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

>> > >>>>>>>>> +                                      strdup(devname), &dev);

>> > >>>>>>>>> +             if (ret)

>> > >>>>>>>>> +                     return ret;

>> > >>>>>>>>> +

>> > >>>>>>>>> +             part_data = dev_get_uclass_plat(dev);

>> > >>>>>>>>> +             part_data->partnum = part;

>> > >>>>>>>>> +             part_data->gpt_part_info = info;

>> > >>>>>>>>> +             count++;

>> > >>>>>>>>> +

>> > >>>>>>>>> +             device_probe(dev);

>> > >>>>>>>>> +     }

>> > >>>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

>> > >>>>>>>>> +

>> > >>>>>>>>> +     return 0;

>> > >>>>>>>>> +}

>> > >>>>>>>>> +

>> > >>>>>>>>>      static int blk_post_probe(struct udevice *dev)

>> > >>>>>>>>>      {

>> > >>>>>>>>>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

>> > >>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>> > >>>>>>>>>         .post_probe     = blk_post_probe,

>> > >>>>>>>>>         .per_device_plat_auto   = sizeof(struct blk_desc),

>> > >>>>>>>>>      };

>> > >>>>>>>>> +

>> > >>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

>> > >>>>>>>>> +                        lbaint_t blkcnt, void *buffer)

>> > >>>>>>>>> +{

>> > >>>>>>>>> +     struct udevice *parent;

>> > >>>>>>>>> +     struct disk_part *part;

>> > >>>>>>>>> +     const struct blk_ops *ops;

>> > >>>>>>>>> +

>> > >>>>>>>>> +     parent = dev_get_parent(dev);

>> > >>>>>>>>

>> > >>>>>>>> What device type will the parent have if it is a eMMC hardware partition?

>> > >>>>>>>>

>> > >>>>>>>>> +     ops = blk_get_ops(parent);

>> > >>>>>>>>> +     if (!ops->read)

>> > >>>>>>>>> +             return -ENOSYS;

>> > >>>>>>>>> +

>> > >>>>>>>>> +     part = dev_get_uclass_plat(dev);

>> > >>>>>>>>

>> > >>>>>>>> You should check that we do not access the block device past the

>> > >>>>>>>> partition end:

>> > >>>>>>>

>> > >>>>>>> Yes, I will fix all of checks.

>> > >>>>>>>

>> > >>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

>> > >>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

>> > >>>>>>>>           return -EFAULT.

>> > >>>>>>>>

>> > >>>>>>>>> +     start += part->gpt_part_info.start;

>> > >>>>>>

>> > >>>>>> A better solution is:

>> > >>>>>>            if (start >= part->gpt_part_info.size)

>> > >>>>>>                    return 0;

>> > >>>>>>

>> > >>>>>>            if ((start + blkcnt) > part->gpt_part_info.size)

>> > >>>>>>                    blkcnt = part->gpt_part_info.size - start;

>> > >>>>>>            start += part->gpt_part_info.start;

>> > >>>>>> instead of returning -EFAULT.

>> > >>>>>> (note that start and blkcnt are in "block".)

>> > >>>>>

>> > >>>>> What is your motivation to support an illegal access?

>> > >>>>>

>> > >>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

>> > >>>>> ReadBlocks() and WriteBlocks() services must return

>> > >>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

>> > >>>>> valid.

>> > >>>>

>> > >>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

>> > >>>> and that if the starting block is out of partition region, we should

>> > >>>> return an error (and if not, we still want to trim IO request to fit

>> > >>>> into partition size as other OS's API like linux does).

>> > >>>> Do you think it's incorrect?

>> > >>>

>> > >>> [..]

>> > >>>

>> > >>> Related to this patch I think that the partition type should be really

>> > >>> be a child of the media device:

>> > >>>

>> > >>> - MMC

>> > >>>       |- BLK

>> > >>>       |- PARTITION

>> > >>>          |- BLK

>> > >>>       |- PARTITION

>> > >>>          |- BLK

>> > >>>       |- PARTITION

>> > >>>          |- BLK

>> > >>>

>> > >>> It seems more natural to me that putting the partitions under the

>> > >>> top-level BLK device, so that BLK remains a 'terminal' device.

>> > >>>

>> > >>> The partition uclass is different from BLK, of course. It could

>> > >>> contain information about the partition such as its partition number

>> > >>> and UUID.

>> > >>

>> > >> Do you mean hardware partition here? Otherwise I would not know what BLK

>> > >> should model.

>> > >

>> > > I mean that (I think) we should not use BLK to model partitions. A BLK

>> > > should just be a block device.

>> >

>> > That is fine. But this implies that a software partition is the child of

>> > a block partition and not the other way round. So the tree should like:

>> >

>> > MMC

>> > |- BLK (user hardware partition)

>> > ||- PARTITION 1 (software partition)

>> > ||- PARTITION 2 (software partition)

>> > |...

>> > ||- PARTITION n (software partition)

>> > |- BLK (rpmb hardware partition)

>> > |- BLK (boot0 hardware partition)

>> > |- BLK (boot1 hardware partition)

>> 

>> I presume you meant to include a BLK device under each PARTITION?

>

>I do understand that PARTITION is not BLK, but thinking that there is always

>one-to-one link between a PARTITION device and a BLK device, what benefit

>will we see in distinguishing one from the other?

>I'm afraid that this makes things a bit complicated.

>

>> But anyway, I was more thinking of this:

>> 

>> MMC

>> | HWPARTITION rpmb

>> || BLK whole rpmb

>> || PARTITION 1

>> ||| BLK

>> || PARTITION 2

>> ||| BLK

>> || PARTITION 3

>> ||| BLK

>> | HWPARTITION boot0

>> || BLK

>> (maybe have PARTITION in here too?

>> | HWPARTITION boot1

>> (maybe have PARTITION in here too?

>> || BLK

>

>I simply wonder why not we see "HWPARTITION" as yet another block device

>[controller] (like scsi LUN's and/or NVME namespaces as discussed in

>a thread of "part: call part_init() in blk_get_device_by_str() only for

>MMC"?).

>

>> >

>> > >

>> > > I don't see any difference between a partition and a hardware

>> > > partition. We presumably end up with a hierarchy though. Do we need a

>> > > HWPARTITION uclass so we can handle the hardware partitions

>> > > differently?

>> >

>> > Software partitions are defined and discovered via partition tables.

>> > Hardware partitions are defined in a hardware specific way.

>> >

>> > All software partitions map to HD() device tree nodes in UEFI.

>> > An MMC device maps to an eMMC() node

>> > MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

>> > do the same in U-Boot.

>> > An SD-card maps to an SD() node.

>> > An NVMe namespace maps to a NVMe() node.

>> > An SCSI LUN maps to a Scsi() node.

>> > SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

>> 

>> I'm not quite sure about the terminology here. I'm not even talking

>> about UEFI, really, just how best to model this stuff in U-Boot.

>

>Anyhow, if we pursue the direction that you suggested here,

>we will end up with having one PARTITION *driver* per partition type,

>efi, dos or iso, under disk/?


We already have one driver per partition table type. They just need to be integrated into the DM model. Partitions are defined by first and last block. They don't depend on the type of the partition table. But you need separate drivers per filesystem.

The block device needs a pointer to the partition table driver.

The partition needs a pointer to the filesystem driver.

Best regards

Heinrich

>

># Oops, extra work :)

>

>Thanks,

>-Takahiro Akashi

>

>

>> In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

>> right? I'm a little worried it is not modelled correctly. After all,

>> what is the parent of a SCSI device?

>> 

>> >

>> > The simple file protocol is only provided by HD() nodes and not by nodes

>> > representing hardware partitions. If the whole hardware partition is

>> > formatted as a file system you would still create a HD() node with

>> > partition number 0.

>> 

>> Regards,

>> Simon

Tom Rini Oct. 12, 2021, 3:14 p.m. UTC | #15

On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:
> Hi Heinrich,

> 

> On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >

> >

> >

> > On 10/11/21 16:54, Simon Glass wrote:

> > > Hi Takahiro,

> > >

> > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > > <takahiro.akashi@linaro.org> wrote:

> > >>

> > >> Heinrich,

> > >>

> > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > >>>

> > >>>

> > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > >>>>>>

> > >>>>>>

> > >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > >>>>>>> UCLASS_PARTITION device will be created as a child node of

> > >>>>>>> UCLASS_BLK device.

> > >>>>>>>

> > >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > >>>>>>> ---

> > >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > >>>>>>>     include/blk.h              |   9 +++

> > >>>>>>>     include/dm/uclass-id.h     |   1 +

> > >>>>>>>     3 files changed, 121 insertions(+)

> > >>>>>>>

> > >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > >>>>>>> --- a/drivers/block/blk-uclass.c

> > >>>>>>> +++ b/drivers/block/blk-uclass.c

> > >>>>>>> @@ -12,6 +12,7 @@

> > >>>>>>>     #include <log.h>

> > >>>>>>>     #include <malloc.h>

> > >>>>>>>     #include <part.h>

> > >>>>>>> +#include <string.h>

> > >>>>>>>     #include <dm/device-internal.h>

> > >>>>>>>     #include <dm/lists.h>

> > >>>>>>>     #include <dm/uclass-internal.h>

> > >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > >>>>>>>        return 0;

> > >>>>>>>     }

> > >>>>>>>

> > >>>>>>> +int blk_create_partitions(struct udevice *parent)

> > >>>>>>> +{

> > >>>>>>> +     int part, count;

> > >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > >>>>>>> +     struct disk_partition info;

> > >>>>>>> +     struct disk_part *part_data;

> > >>>>>>> +     char devname[32];

> > >>>>>>> +     struct udevice *dev;

> > >>>>>>> +     int ret;

> > >>>>>>> +

> > >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > >>>>>>> +             return 0;

> > >>>>>>> +

> > >>>>>>> +     /* Add devices for each partition */

> > >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > >>>>>>> +             if (part_get_info(desc, part, &info))

> > >>>>>>> +                     continue;

> > >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > >>>>>>> +                      part);

> > >>>>>>> +

> > >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > >>>>>>> +                                      strdup(devname), &dev);

> > >>>>>>> +             if (ret)

> > >>>>>>> +                     return ret;

> > >>>>>>> +

> > >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > >>>>>>> +             part_data->partnum = part;

> > >>>>>>> +             part_data->gpt_part_info = info;

> > >>>>>>> +             count++;

> > >>>>>>> +

> > >>>>>>> +             device_probe(dev);

> > >>>>>>> +     }

> > >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > >>>>>>> +

> > >>>>>>> +     return 0;

> > >>>>>>> +}

> > >>>>>>> +

> > >>>>>>>     static int blk_post_probe(struct udevice *dev)

> > >>>>>>>     {

> > >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > >>>>>>>        .post_probe     = blk_post_probe,

> > >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> > >>>>>>>     };

> > >>>>>>> +

> > >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > >>>>>>> +{

> > >>>>>>> +     struct udevice *parent;

> > >>>>>>> +     struct disk_part *part;

> > >>>>>>> +     const struct blk_ops *ops;

> > >>>>>>> +

> > >>>>>>> +     parent = dev_get_parent(dev);

> > >>>>>>

> > >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > >>>>>>

> > >>>>>>> +     ops = blk_get_ops(parent);

> > >>>>>>> +     if (!ops->read)

> > >>>>>>> +             return -ENOSYS;

> > >>>>>>> +

> > >>>>>>> +     part = dev_get_uclass_plat(dev);

> > >>>>>>

> > >>>>>> You should check that we do not access the block device past the

> > >>>>>> partition end:

> > >>>>>

> > >>>>> Yes, I will fix all of checks.

> > >>>>>

> > >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > >>>>>>          return -EFAULT.

> > >>>>>>

> > >>>>>>> +     start += part->gpt_part_info.start;

> > >>>>

> > >>>> A better solution is:

> > >>>>           if (start >= part->gpt_part_info.size)

> > >>>>                   return 0;

> > >>>>

> > >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> > >>>>                   blkcnt = part->gpt_part_info.size - start;

> > >>>>           start += part->gpt_part_info.start;

> > >>>> instead of returning -EFAULT.

> > >>>> (note that start and blkcnt are in "block".)

> > >>>

> > >>> What is your motivation to support an illegal access?

> > >>>

> > >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > >>> ReadBlocks() and WriteBlocks() services must return

> > >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > >>> valid.

> > >>

> > >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > >> and that if the starting block is out of partition region, we should

> > >> return an error (and if not, we still want to trim IO request to fit

> > >> into partition size as other OS's API like linux does).

> > >> Do you think it's incorrect?

> > >

> > > [..]

> > >

> > > Related to this patch I think that the partition type should be really

> > > be a child of the media device:

> > >

> > > - MMC

> > >      |- BLK

> > >      |- PARTITION

> > >         |- BLK

> > >      |- PARTITION

> > >         |- BLK

> > >      |- PARTITION

> > >         |- BLK

> > >

> > > It seems more natural to me that putting the partitions under the

> > > top-level BLK device, so that BLK remains a 'terminal' device.

> > >

> > > The partition uclass is different from BLK, of course. It could

> > > contain information about the partition such as its partition number

> > > and UUID.

> >

> > Do you mean hardware partition here? Otherwise I would not know what BLK

> > should model.

> 

> I mean that (I think) we should not use BLK to model partitions. A BLK

> should just be a block device.

> 

> I don't see any difference between a partition and a hardware

> partition. We presumably end up with a hierarchy though. Do we need a

> HWPARTITION uclass so we can handle the hardware partitions

> differently?


Note that for eMMC devices, hardware partitions are different from
partition-table partitions.  If you boot a system with an eMMC device up
in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and
mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in
U-Boot in that you can access each of these with 'mmc dev N M' where M
defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1
and 3 is the rpmb area.  The 'mmc' command also allows, when possible
and implemented, configuring these partitions, again to the extent
allowed, documented and implemented.

In terms of modeling, this is akin to how if you use a USB card reader
that supports 4 different form-factor cards, you can end up with 4
different devices showing up in Linux (if you have one of the nice card
readers that supports multiple cards at once).

-- 
Tom

AKASHI Takahiro Oct. 13, 2021, 1:32 a.m. UTC | #16

On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:
> On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

> > Hi Heinrich,

> > 

> > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > >

> > >

> > >

> > > On 10/11/21 16:54, Simon Glass wrote:

> > > > Hi Takahiro,

> > > >

> > > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > > > <takahiro.akashi@linaro.org> wrote:

> > > >>

> > > >> Heinrich,

> > > >>

> > > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > > >>>

> > > >>>

> > > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > > >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > >>>>>>

> > > >>>>>>

> > > >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > >>>>>>> UCLASS_PARTITION device will be created as a child node of

> > > >>>>>>> UCLASS_BLK device.

> > > >>>>>>>

> > > >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > >>>>>>> ---

> > > >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > >>>>>>>     include/blk.h              |   9 +++

> > > >>>>>>>     include/dm/uclass-id.h     |   1 +

> > > >>>>>>>     3 files changed, 121 insertions(+)

> > > >>>>>>>

> > > >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > > >>>>>>> --- a/drivers/block/blk-uclass.c

> > > >>>>>>> +++ b/drivers/block/blk-uclass.c

> > > >>>>>>> @@ -12,6 +12,7 @@

> > > >>>>>>>     #include <log.h>

> > > >>>>>>>     #include <malloc.h>

> > > >>>>>>>     #include <part.h>

> > > >>>>>>> +#include <string.h>

> > > >>>>>>>     #include <dm/device-internal.h>

> > > >>>>>>>     #include <dm/lists.h>

> > > >>>>>>>     #include <dm/uclass-internal.h>

> > > >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > >>>>>>>        return 0;

> > > >>>>>>>     }

> > > >>>>>>>

> > > >>>>>>> +int blk_create_partitions(struct udevice *parent)

> > > >>>>>>> +{

> > > >>>>>>> +     int part, count;

> > > >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > >>>>>>> +     struct disk_partition info;

> > > >>>>>>> +     struct disk_part *part_data;

> > > >>>>>>> +     char devname[32];

> > > >>>>>>> +     struct udevice *dev;

> > > >>>>>>> +     int ret;

> > > >>>>>>> +

> > > >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > >>>>>>> +             return 0;

> > > >>>>>>> +

> > > >>>>>>> +     /* Add devices for each partition */

> > > >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > >>>>>>> +             if (part_get_info(desc, part, &info))

> > > >>>>>>> +                     continue;

> > > >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > >>>>>>> +                      part);

> > > >>>>>>> +

> > > >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > > >>>>>>> +                                      strdup(devname), &dev);

> > > >>>>>>> +             if (ret)

> > > >>>>>>> +                     return ret;

> > > >>>>>>> +

> > > >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > > >>>>>>> +             part_data->partnum = part;

> > > >>>>>>> +             part_data->gpt_part_info = info;

> > > >>>>>>> +             count++;

> > > >>>>>>> +

> > > >>>>>>> +             device_probe(dev);

> > > >>>>>>> +     }

> > > >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > >>>>>>> +

> > > >>>>>>> +     return 0;

> > > >>>>>>> +}

> > > >>>>>>> +

> > > >>>>>>>     static int blk_post_probe(struct udevice *dev)

> > > >>>>>>>     {

> > > >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > >>>>>>>        .post_probe     = blk_post_probe,

> > > >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> > > >>>>>>>     };

> > > >>>>>>> +

> > > >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > > >>>>>>> +{

> > > >>>>>>> +     struct udevice *parent;

> > > >>>>>>> +     struct disk_part *part;

> > > >>>>>>> +     const struct blk_ops *ops;

> > > >>>>>>> +

> > > >>>>>>> +     parent = dev_get_parent(dev);

> > > >>>>>>

> > > >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > > >>>>>>

> > > >>>>>>> +     ops = blk_get_ops(parent);

> > > >>>>>>> +     if (!ops->read)

> > > >>>>>>> +             return -ENOSYS;

> > > >>>>>>> +

> > > >>>>>>> +     part = dev_get_uclass_plat(dev);

> > > >>>>>>

> > > >>>>>> You should check that we do not access the block device past the

> > > >>>>>> partition end:

> > > >>>>>

> > > >>>>> Yes, I will fix all of checks.

> > > >>>>>

> > > >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > >>>>>>          return -EFAULT.

> > > >>>>>>

> > > >>>>>>> +     start += part->gpt_part_info.start;

> > > >>>>

> > > >>>> A better solution is:

> > > >>>>           if (start >= part->gpt_part_info.size)

> > > >>>>                   return 0;

> > > >>>>

> > > >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> > > >>>>                   blkcnt = part->gpt_part_info.size - start;

> > > >>>>           start += part->gpt_part_info.start;

> > > >>>> instead of returning -EFAULT.

> > > >>>> (note that start and blkcnt are in "block".)

> > > >>>

> > > >>> What is your motivation to support an illegal access?

> > > >>>

> > > >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > > >>> ReadBlocks() and WriteBlocks() services must return

> > > >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > > >>> valid.

> > > >>

> > > >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > > >> and that if the starting block is out of partition region, we should

> > > >> return an error (and if not, we still want to trim IO request to fit

> > > >> into partition size as other OS's API like linux does).

> > > >> Do you think it's incorrect?

> > > >

> > > > [..]

> > > >

> > > > Related to this patch I think that the partition type should be really

> > > > be a child of the media device:

> > > >

> > > > - MMC

> > > >      |- BLK

> > > >      |- PARTITION

> > > >         |- BLK

> > > >      |- PARTITION

> > > >         |- BLK

> > > >      |- PARTITION

> > > >         |- BLK

> > > >

> > > > It seems more natural to me that putting the partitions under the

> > > > top-level BLK device, so that BLK remains a 'terminal' device.

> > > >

> > > > The partition uclass is different from BLK, of course. It could

> > > > contain information about the partition such as its partition number

> > > > and UUID.

> > >

> > > Do you mean hardware partition here? Otherwise I would not know what BLK

> > > should model.

> > 

> > I mean that (I think) we should not use BLK to model partitions. A BLK

> > should just be a block device.

> > 

> > I don't see any difference between a partition and a hardware

> > partition. We presumably end up with a hierarchy though. Do we need a

> > HWPARTITION uclass so we can handle the hardware partitions

> > differently?

> 

> Note that for eMMC devices, hardware partitions are different from

> partition-table partitions.  If you boot a system with an eMMC device up

> in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

> mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

> U-Boot in that you can access each of these with 'mmc dev N M' where M

> defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

> and 3 is the rpmb area.  The 'mmc' command also allows, when possible

> and implemented, configuring these partitions, again to the extent

> allowed, documented and implemented.


Thank you. That is exactly what I tried to mention in my reply
at "part: call part_init() in blk_get_device_by_str() only for MMC"

---8<---
# On the other hand, we have to explicitly switch "hw partitions"
# with blk_select_hwpart_devnum() on MMC devices even though we use
# the *same* udevice(blk_desc).
--->8---

The problem with the current U-Boot driver model is that all of "mmcblkN,
mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same
udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()
to distinguish them.

When it comes to UEFI, I hope we can currently support hw partitions
in this way:
  => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""
(".1" is a key, I have never tried this syntax though.)

But probably its device path won't be properly formatted
as expected as Heinrich suggested.

-Takahiro Akashi


> In terms of modeling, this is akin to how if you use a USB card reader

> that supports 4 different form-factor cards, you can end up with 4

> different devices showing up in Linux (if you have one of the nice card

> readers that supports multiple cards at once).

> 

> -- 

> Tom

Simon Glass Oct. 13, 2021, 6:05 p.m. UTC | #17

Hi Takahiro,

On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>

> On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:

> > On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

> > > Hi Heinrich,

> > >

> > > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > > >

> > > >

> > > >

> > > > On 10/11/21 16:54, Simon Glass wrote:

> > > > > Hi Takahiro,

> > > > >

> > > > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > > > > <takahiro.akashi@linaro.org> wrote:

> > > > >>

> > > > >> Heinrich,

> > > > >>

> > > > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > > > >>>

> > > > >>>

> > > > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > > > >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > > >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > > >>>>>>

> > > > >>>>>>

> > > > >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > > >>>>>>> UCLASS_PARTITION device will be created as a child node of

> > > > >>>>>>> UCLASS_BLK device.

> > > > >>>>>>>

> > > > >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > > >>>>>>> ---

> > > > >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > > >>>>>>>     include/blk.h              |   9 +++

> > > > >>>>>>>     include/dm/uclass-id.h     |   1 +

> > > > >>>>>>>     3 files changed, 121 insertions(+)

> > > > >>>>>>>

> > > > >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > > >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > > > >>>>>>> --- a/drivers/block/blk-uclass.c

> > > > >>>>>>> +++ b/drivers/block/blk-uclass.c

> > > > >>>>>>> @@ -12,6 +12,7 @@

> > > > >>>>>>>     #include <log.h>

> > > > >>>>>>>     #include <malloc.h>

> > > > >>>>>>>     #include <part.h>

> > > > >>>>>>> +#include <string.h>

> > > > >>>>>>>     #include <dm/device-internal.h>

> > > > >>>>>>>     #include <dm/lists.h>

> > > > >>>>>>>     #include <dm/uclass-internal.h>

> > > > >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > > >>>>>>>        return 0;

> > > > >>>>>>>     }

> > > > >>>>>>>

> > > > >>>>>>> +int blk_create_partitions(struct udevice *parent)

> > > > >>>>>>> +{

> > > > >>>>>>> +     int part, count;

> > > > >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > >>>>>>> +     struct disk_partition info;

> > > > >>>>>>> +     struct disk_part *part_data;

> > > > >>>>>>> +     char devname[32];

> > > > >>>>>>> +     struct udevice *dev;

> > > > >>>>>>> +     int ret;

> > > > >>>>>>> +

> > > > >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > > >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > > >>>>>>> +             return 0;

> > > > >>>>>>> +

> > > > >>>>>>> +     /* Add devices for each partition */

> > > > >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > > >>>>>>> +             if (part_get_info(desc, part, &info))

> > > > >>>>>>> +                     continue;

> > > > >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > > >>>>>>> +                      part);

> > > > >>>>>>> +

> > > > >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > > > >>>>>>> +                                      strdup(devname), &dev);

> > > > >>>>>>> +             if (ret)

> > > > >>>>>>> +                     return ret;

> > > > >>>>>>> +

> > > > >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > > > >>>>>>> +             part_data->partnum = part;

> > > > >>>>>>> +             part_data->gpt_part_info = info;

> > > > >>>>>>> +             count++;

> > > > >>>>>>> +

> > > > >>>>>>> +             device_probe(dev);

> > > > >>>>>>> +     }

> > > > >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > > >>>>>>> +

> > > > >>>>>>> +     return 0;

> > > > >>>>>>> +}

> > > > >>>>>>> +

> > > > >>>>>>>     static int blk_post_probe(struct udevice *dev)

> > > > >>>>>>>     {

> > > > >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > > >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > > >>>>>>>        .post_probe     = blk_post_probe,

> > > > >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> > > > >>>>>>>     };

> > > > >>>>>>> +

> > > > >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > > >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > > > >>>>>>> +{

> > > > >>>>>>> +     struct udevice *parent;

> > > > >>>>>>> +     struct disk_part *part;

> > > > >>>>>>> +     const struct blk_ops *ops;

> > > > >>>>>>> +

> > > > >>>>>>> +     parent = dev_get_parent(dev);

> > > > >>>>>>

> > > > >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > > > >>>>>>

> > > > >>>>>>> +     ops = blk_get_ops(parent);

> > > > >>>>>>> +     if (!ops->read)

> > > > >>>>>>> +             return -ENOSYS;

> > > > >>>>>>> +

> > > > >>>>>>> +     part = dev_get_uclass_plat(dev);

> > > > >>>>>>

> > > > >>>>>> You should check that we do not access the block device past the

> > > > >>>>>> partition end:

> > > > >>>>>

> > > > >>>>> Yes, I will fix all of checks.

> > > > >>>>>

> > > > >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > > >>>>>>          return -EFAULT.

> > > > >>>>>>

> > > > >>>>>>> +     start += part->gpt_part_info.start;

> > > > >>>>

> > > > >>>> A better solution is:

> > > > >>>>           if (start >= part->gpt_part_info.size)

> > > > >>>>                   return 0;

> > > > >>>>

> > > > >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> > > > >>>>                   blkcnt = part->gpt_part_info.size - start;

> > > > >>>>           start += part->gpt_part_info.start;

> > > > >>>> instead of returning -EFAULT.

> > > > >>>> (note that start and blkcnt are in "block".)

> > > > >>>

> > > > >>> What is your motivation to support an illegal access?

> > > > >>>

> > > > >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > > > >>> ReadBlocks() and WriteBlocks() services must return

> > > > >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > > > >>> valid.

> > > > >>

> > > > >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > > > >> and that if the starting block is out of partition region, we should

> > > > >> return an error (and if not, we still want to trim IO request to fit

> > > > >> into partition size as other OS's API like linux does).

> > > > >> Do you think it's incorrect?

> > > > >

> > > > > [..]

> > > > >

> > > > > Related to this patch I think that the partition type should be really

> > > > > be a child of the media device:

> > > > >

> > > > > - MMC

> > > > >      |- BLK

> > > > >      |- PARTITION

> > > > >         |- BLK

> > > > >      |- PARTITION

> > > > >         |- BLK

> > > > >      |- PARTITION

> > > > >         |- BLK

> > > > >

> > > > > It seems more natural to me that putting the partitions under the

> > > > > top-level BLK device, so that BLK remains a 'terminal' device.

> > > > >

> > > > > The partition uclass is different from BLK, of course. It could

> > > > > contain information about the partition such as its partition number

> > > > > and UUID.

> > > >

> > > > Do you mean hardware partition here? Otherwise I would not know what BLK

> > > > should model.

> > >

> > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > should just be a block device.

> > >

> > > I don't see any difference between a partition and a hardware

> > > partition. We presumably end up with a hierarchy though. Do we need a

> > > HWPARTITION uclass so we can handle the hardware partitions

> > > differently?

> >

> > Note that for eMMC devices, hardware partitions are different from

> > partition-table partitions.  If you boot a system with an eMMC device up

> > in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

> > mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

> > U-Boot in that you can access each of these with 'mmc dev N M' where M

> > defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

> > and 3 is the rpmb area.  The 'mmc' command also allows, when possible

> > and implemented, configuring these partitions, again to the extent

> > allowed, documented and implemented.

>

> Thank you. That is exactly what I tried to mention in my reply

> at "part: call part_init() in blk_get_device_by_str() only for MMC"


OK so it sounds like we agree that hwpartition and partition are
different things.

>

> ---8<---

> # On the other hand, we have to explicitly switch "hw partitions"

> # with blk_select_hwpart_devnum() on MMC devices even though we use

> # the *same* udevice(blk_desc).

> --->8---

>

> The problem with the current U-Boot driver model is that all of "mmcblkN,

> mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same

> udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()

> to distinguish them.


Here's our chance to rethink this. What should the device hierarchy be
for an MMC device? I made a proposal further up the thread.

>

> When it comes to UEFI, I hope we can currently support hw partitions

> in this way:

>   => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""

> (".1" is a key, I have never tried this syntax though.)

>

> But probably its device path won't be properly formatted

> as expected as Heinrich suggested.

>

> -Takahiro Akashi

>

>

> > In terms of modeling, this is akin to how if you use a USB card reader

> > that supports 4 different form-factor cards, you can end up with 4

> > different devices showing up in Linux (if you have one of the nice card

> > readers that supports multiple cards at once).

> >

> > --

> > Tom

>

>


Regards,
Simon

AKASHI Takahiro Oct. 14, 2021, 8:03 a.m. UTC | #18

Simon,

On Wed, Oct 13, 2021 at 12:05:58PM -0600, Simon Glass wrote:
> Hi Takahiro,

> 

> On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro

> <takahiro.akashi@linaro.org> wrote:

> >

> > On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:

> > > On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

> > > > Hi Heinrich,

> > > >

> > > > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > > > >

> > > > >

> > > > >

> > > > > On 10/11/21 16:54, Simon Glass wrote:

> > > > > > Hi Takahiro,

> > > > > >

> > > > > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > > > > > <takahiro.akashi@linaro.org> wrote:

> > > > > >>

> > > > > >> Heinrich,

> > > > > >>

> > > > > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > > > > >>>

> > > > > >>>

> > > > > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > > > > >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > > > >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > > > >>>>>>

> > > > > >>>>>>

> > > > > >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > > > >>>>>>> UCLASS_PARTITION device will be created as a child node of

> > > > > >>>>>>> UCLASS_BLK device.

> > > > > >>>>>>>

> > > > > >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > > > >>>>>>> ---

> > > > > >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > > > >>>>>>>     include/blk.h              |   9 +++

> > > > > >>>>>>>     include/dm/uclass-id.h     |   1 +

> > > > > >>>>>>>     3 files changed, 121 insertions(+)

> > > > > >>>>>>>

> > > > > >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > > > >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > > > > >>>>>>> --- a/drivers/block/blk-uclass.c

> > > > > >>>>>>> +++ b/drivers/block/blk-uclass.c

> > > > > >>>>>>> @@ -12,6 +12,7 @@

> > > > > >>>>>>>     #include <log.h>

> > > > > >>>>>>>     #include <malloc.h>

> > > > > >>>>>>>     #include <part.h>

> > > > > >>>>>>> +#include <string.h>

> > > > > >>>>>>>     #include <dm/device-internal.h>

> > > > > >>>>>>>     #include <dm/lists.h>

> > > > > >>>>>>>     #include <dm/uclass-internal.h>

> > > > > >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > > > >>>>>>>        return 0;

> > > > > >>>>>>>     }

> > > > > >>>>>>>

> > > > > >>>>>>> +int blk_create_partitions(struct udevice *parent)

> > > > > >>>>>>> +{

> > > > > >>>>>>> +     int part, count;

> > > > > >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > >>>>>>> +     struct disk_partition info;

> > > > > >>>>>>> +     struct disk_part *part_data;

> > > > > >>>>>>> +     char devname[32];

> > > > > >>>>>>> +     struct udevice *dev;

> > > > > >>>>>>> +     int ret;

> > > > > >>>>>>> +

> > > > > >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > > > >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > > > >>>>>>> +             return 0;

> > > > > >>>>>>> +

> > > > > >>>>>>> +     /* Add devices for each partition */

> > > > > >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > > > >>>>>>> +             if (part_get_info(desc, part, &info))

> > > > > >>>>>>> +                     continue;

> > > > > >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > > > >>>>>>> +                      part);

> > > > > >>>>>>> +

> > > > > >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > > > > >>>>>>> +                                      strdup(devname), &dev);

> > > > > >>>>>>> +             if (ret)

> > > > > >>>>>>> +                     return ret;

> > > > > >>>>>>> +

> > > > > >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > > > > >>>>>>> +             part_data->partnum = part;

> > > > > >>>>>>> +             part_data->gpt_part_info = info;

> > > > > >>>>>>> +             count++;

> > > > > >>>>>>> +

> > > > > >>>>>>> +             device_probe(dev);

> > > > > >>>>>>> +     }

> > > > > >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > > > >>>>>>> +

> > > > > >>>>>>> +     return 0;

> > > > > >>>>>>> +}

> > > > > >>>>>>> +

> > > > > >>>>>>>     static int blk_post_probe(struct udevice *dev)

> > > > > >>>>>>>     {

> > > > > >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > > > >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > > > >>>>>>>        .post_probe     = blk_post_probe,

> > > > > >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> > > > > >>>>>>>     };

> > > > > >>>>>>> +

> > > > > >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > > > >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > > > > >>>>>>> +{

> > > > > >>>>>>> +     struct udevice *parent;

> > > > > >>>>>>> +     struct disk_part *part;

> > > > > >>>>>>> +     const struct blk_ops *ops;

> > > > > >>>>>>> +

> > > > > >>>>>>> +     parent = dev_get_parent(dev);

> > > > > >>>>>>

> > > > > >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > > > > >>>>>>

> > > > > >>>>>>> +     ops = blk_get_ops(parent);

> > > > > >>>>>>> +     if (!ops->read)

> > > > > >>>>>>> +             return -ENOSYS;

> > > > > >>>>>>> +

> > > > > >>>>>>> +     part = dev_get_uclass_plat(dev);

> > > > > >>>>>>

> > > > > >>>>>> You should check that we do not access the block device past the

> > > > > >>>>>> partition end:

> > > > > >>>>>

> > > > > >>>>> Yes, I will fix all of checks.

> > > > > >>>>>

> > > > > >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > > > >>>>>>          return -EFAULT.

> > > > > >>>>>>

> > > > > >>>>>>> +     start += part->gpt_part_info.start;

> > > > > >>>>

> > > > > >>>> A better solution is:

> > > > > >>>>           if (start >= part->gpt_part_info.size)

> > > > > >>>>                   return 0;

> > > > > >>>>

> > > > > >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> > > > > >>>>                   blkcnt = part->gpt_part_info.size - start;

> > > > > >>>>           start += part->gpt_part_info.start;

> > > > > >>>> instead of returning -EFAULT.

> > > > > >>>> (note that start and blkcnt are in "block".)

> > > > > >>>

> > > > > >>> What is your motivation to support an illegal access?

> > > > > >>>

> > > > > >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > > > > >>> ReadBlocks() and WriteBlocks() services must return

> > > > > >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > > > > >>> valid.

> > > > > >>

> > > > > >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > > > > >> and that if the starting block is out of partition region, we should

> > > > > >> return an error (and if not, we still want to trim IO request to fit

> > > > > >> into partition size as other OS's API like linux does).

> > > > > >> Do you think it's incorrect?

> > > > > >

> > > > > > [..]

> > > > > >

> > > > > > Related to this patch I think that the partition type should be really

> > > > > > be a child of the media device:

> > > > > >

> > > > > > - MMC

> > > > > >      |- BLK

> > > > > >      |- PARTITION

> > > > > >         |- BLK

> > > > > >      |- PARTITION

> > > > > >         |- BLK

> > > > > >      |- PARTITION

> > > > > >         |- BLK

> > > > > >

> > > > > > It seems more natural to me that putting the partitions under the

> > > > > > top-level BLK device, so that BLK remains a 'terminal' device.

> > > > > >

> > > > > > The partition uclass is different from BLK, of course. It could

> > > > > > contain information about the partition such as its partition number

> > > > > > and UUID.

> > > > >

> > > > > Do you mean hardware partition here? Otherwise I would not know what BLK

> > > > > should model.

> > > >

> > > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > > should just be a block device.

> > > >

> > > > I don't see any difference between a partition and a hardware

> > > > partition. We presumably end up with a hierarchy though. Do we need a

> > > > HWPARTITION uclass so we can handle the hardware partitions

> > > > differently?

> > >

> > > Note that for eMMC devices, hardware partitions are different from

> > > partition-table partitions.  If you boot a system with an eMMC device up

> > > in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

> > > mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

> > > U-Boot in that you can access each of these with 'mmc dev N M' where M

> > > defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

> > > and 3 is the rpmb area.  The 'mmc' command also allows, when possible

> > > and implemented, configuring these partitions, again to the extent

> > > allowed, documented and implemented.

> >

> > Thank you. That is exactly what I tried to mention in my reply

> > at "part: call part_init() in blk_get_device_by_str() only for MMC"

> 

> OK so it sounds like we agree that hwpartition and partition are

> different things.


Yes.
Please note, IIUC, that
* MMC hw partitions on a device are mapped to one udevice, differentiating
  them by blk_desc->hwpart.
* Each NVME namespace on a device is mapped to a different udevice with
  a different blk_desc->devnum (and nvme_dev->ns_id).
* Each UFS partition (or which is, I suppose, equivalent to scsi LUN) on
  a device is mapped to a different udevice with a different blk_desc->devnum
  (and blk_desc->lun).

So even though those type of devices have some kind of hardware partitions,
they are modelled differently in U-Boot.
(Obviously, I might be wrong here as I'm not quite familiar yet.)

> >

> > ---8<---

> > # On the other hand, we have to explicitly switch "hw partitions"

> > # with blk_select_hwpart_devnum() on MMC devices even though we use

> > # the *same* udevice(blk_desc).

> > --->8---

> >

> > The problem with the current U-Boot driver model is that all of "mmcblkN,

> > mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same

> > udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()

> > to distinguish them.

> 

> Here's our chance to rethink this. What should the device hierarchy be

> for an MMC device? I made a proposal further up the thread.


Well,

On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:
> On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:


> > >>> [..]


> > >>> Related to this patch I think that the partition type should be really

> > >>> be a child of the media device:

> > >>>

> > >>> - MMC

> > >>>       |- BLK

> > >>>       |- PARTITION

> > >>>          |- BLK

> > >>>       |- PARTITION

> > >>>          |- BLK

> > >>>       |- PARTITION

> > >>>          |- BLK

> > >>>

> > >>> It seems more natural to me that putting the partitions under the

> > >>> top-level BLK device, so that BLK remains a 'terminal' device.

> > >>>

> > >>> The partition uclass is different from BLK, of course. It could

> > >>> contain information about the partition such as its partition number

> > >>> and UUID.


Yeah, but there is always 1-to-1 mapping between a partition and
a block (for a partition), so I still wonder whether it makes sense
to model partitions in the way above.

Alternatively, the following hierarchy also makes some sense.
(This is not what I have in my RFC though.)
- MMC
|- BLK (whole disk with part=0)
|- BLK (partition 1)
|- BLK (partition 2)
|- BLK (partition 3)

or

- MMC
|- DISK (whole disk)
||- BLK (partition 0)
||- BLK (partition 1)
||- BLK (partition 2)
||- BLK (partition 3)

Here
MMC: provides read/write operations (via blk_ops)
DISK: holds a geometry of a whole disk and other info
BLK: partition info (+ blk_ops + geo) (part=0 means a while disk)

> > >> Do you mean hardware partition here? Otherwise I would not know what BLK

> > >> should model.

> > >

> > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > should just be a block device.

> >

> > That is fine. But this implies that a software partition is the child of

> > a block partition and not the other way round. So the tree should like:

> >

> > MMC

> > |- BLK (user hardware partition)

> > ||- PARTITION 1 (software partition)

> > ||- PARTITION 2 (software partition)

> > |...

> > ||- PARTITION n (software partition)

> > |- BLK (rpmb hardware partition)

> > |- BLK (boot0 hardware partition)

> > |- BLK (boot1 hardware partition)

> 

> I presume you meant to include a BLK device under each PARTITION?

> 

> But anyway, I was more thinking of this:

> 

> MMC

> | HWPARTITION rpmb

> || BLK whole rpmb

> || PARTITION 1

> ||| BLK

> || PARTITION 2

> ||| BLK

> || PARTITION 3


Do we have any reason to model a RPMB partition as a block device?
For linux, at least, mmcblkrpmb looks to be a character device.

> ||| BLK

> | HWPARTITION boot0

> || BLK

> (maybe have PARTITION in here too?


I don't know how boot partitions are used on a production system.
It's unlikely to have partitions on them given the purpose of "boot"
partitions?

> | HWPARTITION boot1

> (maybe have PARTITION in here too?

> || BLK

> 

> >

> > >

> > > I don't see any difference between a partition and a hardware

> > > partition. We presumably end up with a hierarchy though. Do we need a

> > > HWPARTITION uclass so we can handle the hardware partitions

> > > differently?

> >

> > Software partitions are defined and discovered via partition tables.

> > Hardware partitions are defined in a hardware specific way.

> >

> > All software partitions map to HD() device tree nodes in UEFI.

> > An MMC device maps to an eMMC() node

> > MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

> > do the same in U-Boot.

> > An SD-card maps to an SD() node.

> > An NVMe namespace maps to a NVMe() node.

> > An SCSI LUN maps to a Scsi() node.

> > SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

> 

> I'm not quite sure about the terminology here. I'm not even talking

> about UEFI, really, just how best to model this stuff in U-Boot.


In UEFI world, each efi_disk has its own device path to identify the device.
For example, here is a text representation of device path for a scsi disk
partition:
  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a)

which is set to be created from a corresponding udevice (more strictly
blkc_desc + part).

So the issue Heinrich raised here is a matter of implementation of
this conversion (software partitions, and SCSI channels?) as well as
a modeling for some device type on U-Boot, i.e. MMC hardware partitions.

-Takahiro Akashi

> In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

> right? I'm a little worried it is not modelled correctly. After all,

> what is the parent of a SCSI device?

> 

> >

> > The simple file protocol is only provided by HD() nodes and not by nodes

> > representing hardware partitions. If the whole hardware partition is

> > formatted as a file system you would still create a HD() node with

> > partition number 0.

> 

> Regards,

> Simon

---
> 

> >

> > When it comes to UEFI, I hope we can currently support hw partitions

> > in this way:

> >   => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""

> > (".1" is a key, I have never tried this syntax though.)

> >

> > But probably its device path won't be properly formatted

> > as expected as Heinrich suggested.

> >

> > -Takahiro Akashi

> >

> >

> > > In terms of modeling, this is akin to how if you use a USB card reader

> > > that supports 4 different form-factor cards, you can end up with 4

> > > different devices showing up in Linux (if you have one of the nice card

> > > readers that supports multiple cards at once).

> > >

> > > --

> > > Tom

> >

> >

> 

> Regards,

> Simon

Simon Glass Oct. 14, 2021, 8:55 p.m. UTC | #19

Hi Takahiro,

On Thu, 14 Oct 2021 at 02:03, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>

> Simon,

>

> On Wed, Oct 13, 2021 at 12:05:58PM -0600, Simon Glass wrote:

> > Hi Takahiro,

> >

> > On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro

> > <takahiro.akashi@linaro.org> wrote:

> > >

> > > On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:

> > > > On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

> > > > > Hi Heinrich,

> > > > >

> > > > > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > > > > >

> > > > > >

> > > > > >

> > > > > > On 10/11/21 16:54, Simon Glass wrote:

> > > > > > > Hi Takahiro,

> > > > > > >

> > > > > > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > > > > > > <takahiro.akashi@linaro.org> wrote:

> > > > > > >>

> > > > > > >> Heinrich,

> > > > > > >>

> > > > > > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > > > > > >>>

> > > > > > >>>

> > > > > > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > > > > > >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > > > > >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > > > > >>>>>>

> > > > > > >>>>>>

> > > > > > >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > > > > >>>>>>> UCLASS_PARTITION device will be created as a child node of

> > > > > > >>>>>>> UCLASS_BLK device.

> > > > > > >>>>>>>

> > > > > > >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > > > > >>>>>>> ---

> > > > > > >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > > > > >>>>>>>     include/blk.h              |   9 +++

> > > > > > >>>>>>>     include/dm/uclass-id.h     |   1 +

> > > > > > >>>>>>>     3 files changed, 121 insertions(+)

> > > > > > >>>>>>>

> > > > > > >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > > > > >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > > > > > >>>>>>> --- a/drivers/block/blk-uclass.c

> > > > > > >>>>>>> +++ b/drivers/block/blk-uclass.c

> > > > > > >>>>>>> @@ -12,6 +12,7 @@

> > > > > > >>>>>>>     #include <log.h>

> > > > > > >>>>>>>     #include <malloc.h>

> > > > > > >>>>>>>     #include <part.h>

> > > > > > >>>>>>> +#include <string.h>

> > > > > > >>>>>>>     #include <dm/device-internal.h>

> > > > > > >>>>>>>     #include <dm/lists.h>

> > > > > > >>>>>>>     #include <dm/uclass-internal.h>

> > > > > > >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > > > > >>>>>>>        return 0;

> > > > > > >>>>>>>     }

> > > > > > >>>>>>>

> > > > > > >>>>>>> +int blk_create_partitions(struct udevice *parent)

> > > > > > >>>>>>> +{

> > > > > > >>>>>>> +     int part, count;

> > > > > > >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > > >>>>>>> +     struct disk_partition info;

> > > > > > >>>>>>> +     struct disk_part *part_data;

> > > > > > >>>>>>> +     char devname[32];

> > > > > > >>>>>>> +     struct udevice *dev;

> > > > > > >>>>>>> +     int ret;

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > > > > >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > > > > >>>>>>> +             return 0;

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +     /* Add devices for each partition */

> > > > > > >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > > > > >>>>>>> +             if (part_get_info(desc, part, &info))

> > > > > > >>>>>>> +                     continue;

> > > > > > >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > > > > >>>>>>> +                      part);

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > > > > > >>>>>>> +                                      strdup(devname), &dev);

> > > > > > >>>>>>> +             if (ret)

> > > > > > >>>>>>> +                     return ret;

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > > > > > >>>>>>> +             part_data->partnum = part;

> > > > > > >>>>>>> +             part_data->gpt_part_info = info;

> > > > > > >>>>>>> +             count++;

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +             device_probe(dev);

> > > > > > >>>>>>> +     }

> > > > > > >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +     return 0;

> > > > > > >>>>>>> +}

> > > > > > >>>>>>> +

> > > > > > >>>>>>>     static int blk_post_probe(struct udevice *dev)

> > > > > > >>>>>>>     {

> > > > > > >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > > > > >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > > > > >>>>>>>        .post_probe     = blk_post_probe,

> > > > > > >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> > > > > > >>>>>>>     };

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > > > > >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > > > > > >>>>>>> +{

> > > > > > >>>>>>> +     struct udevice *parent;

> > > > > > >>>>>>> +     struct disk_part *part;

> > > > > > >>>>>>> +     const struct blk_ops *ops;

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +     parent = dev_get_parent(dev);

> > > > > > >>>>>>

> > > > > > >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > > > > > >>>>>>

> > > > > > >>>>>>> +     ops = blk_get_ops(parent);

> > > > > > >>>>>>> +     if (!ops->read)

> > > > > > >>>>>>> +             return -ENOSYS;

> > > > > > >>>>>>> +

> > > > > > >>>>>>> +     part = dev_get_uclass_plat(dev);

> > > > > > >>>>>>

> > > > > > >>>>>> You should check that we do not access the block device past the

> > > > > > >>>>>> partition end:

> > > > > > >>>>>

> > > > > > >>>>> Yes, I will fix all of checks.

> > > > > > >>>>>

> > > > > > >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > > >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > > > > >>>>>>          return -EFAULT.

> > > > > > >>>>>>

> > > > > > >>>>>>> +     start += part->gpt_part_info.start;

> > > > > > >>>>

> > > > > > >>>> A better solution is:

> > > > > > >>>>           if (start >= part->gpt_part_info.size)

> > > > > > >>>>                   return 0;

> > > > > > >>>>

> > > > > > >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> > > > > > >>>>                   blkcnt = part->gpt_part_info.size - start;

> > > > > > >>>>           start += part->gpt_part_info.start;

> > > > > > >>>> instead of returning -EFAULT.

> > > > > > >>>> (note that start and blkcnt are in "block".)

> > > > > > >>>

> > > > > > >>> What is your motivation to support an illegal access?

> > > > > > >>>

> > > > > > >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > > > > > >>> ReadBlocks() and WriteBlocks() services must return

> > > > > > >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > > > > > >>> valid.

> > > > > > >>

> > > > > > >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > > > > > >> and that if the starting block is out of partition region, we should

> > > > > > >> return an error (and if not, we still want to trim IO request to fit

> > > > > > >> into partition size as other OS's API like linux does).

> > > > > > >> Do you think it's incorrect?

> > > > > > >

> > > > > > > [..]

> > > > > > >

> > > > > > > Related to this patch I think that the partition type should be really

> > > > > > > be a child of the media device:

> > > > > > >

> > > > > > > - MMC

> > > > > > >      |- BLK

> > > > > > >      |- PARTITION

> > > > > > >         |- BLK

> > > > > > >      |- PARTITION

> > > > > > >         |- BLK

> > > > > > >      |- PARTITION

> > > > > > >         |- BLK

> > > > > > >

> > > > > > > It seems more natural to me that putting the partitions under the

> > > > > > > top-level BLK device, so that BLK remains a 'terminal' device.

> > > > > > >

> > > > > > > The partition uclass is different from BLK, of course. It could

> > > > > > > contain information about the partition such as its partition number

> > > > > > > and UUID.

> > > > > >

> > > > > > Do you mean hardware partition here? Otherwise I would not know what BLK

> > > > > > should model.

> > > > >

> > > > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > > > should just be a block device.

> > > > >

> > > > > I don't see any difference between a partition and a hardware

> > > > > partition. We presumably end up with a hierarchy though. Do we need a

> > > > > HWPARTITION uclass so we can handle the hardware partitions

> > > > > differently?

> > > >

> > > > Note that for eMMC devices, hardware partitions are different from

> > > > partition-table partitions.  If you boot a system with an eMMC device up

> > > > in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

> > > > mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

> > > > U-Boot in that you can access each of these with 'mmc dev N M' where M

> > > > defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

> > > > and 3 is the rpmb area.  The 'mmc' command also allows, when possible

> > > > and implemented, configuring these partitions, again to the extent

> > > > allowed, documented and implemented.

> > >

> > > Thank you. That is exactly what I tried to mention in my reply

> > > at "part: call part_init() in blk_get_device_by_str() only for MMC"

> >

> > OK so it sounds like we agree that hwpartition and partition are

> > different things.

>

> Yes.

> Please note, IIUC, that

> * MMC hw partitions on a device are mapped to one udevice, differentiating

>   them by blk_desc->hwpart.

> * Each NVME namespace on a device is mapped to a different udevice with

>   a different blk_desc->devnum (and nvme_dev->ns_id).

> * Each UFS partition (or which is, I suppose, equivalent to scsi LUN) on

>   a device is mapped to a different udevice with a different blk_desc->devnum

>   (and blk_desc->lun).

>

> So even though those type of devices have some kind of hardware partitions,

> they are modelled differently in U-Boot.

> (Obviously, I might be wrong here as I'm not quite familiar yet.)

>

> > >

> > > ---8<---

> > > # On the other hand, we have to explicitly switch "hw partitions"

> > > # with blk_select_hwpart_devnum() on MMC devices even though we use

> > > # the *same* udevice(blk_desc).

> > > --->8---

> > >

> > > The problem with the current U-Boot driver model is that all of "mmcblkN,

> > > mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same

> > > udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()

> > > to distinguish them.

> >

> > Here's our chance to rethink this. What should the device hierarchy be

> > for an MMC device? I made a proposal further up the thread.

>

> Well,

>

> On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:

> > On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

>

> > > >>> [..]

>

> > > >>> Related to this patch I think that the partition type should be really

> > > >>> be a child of the media device:

> > > >>>

> > > >>> - MMC

> > > >>>       |- BLK

> > > >>>       |- PARTITION

> > > >>>          |- BLK

> > > >>>       |- PARTITION

> > > >>>          |- BLK

> > > >>>       |- PARTITION

> > > >>>          |- BLK

> > > >>>

> > > >>> It seems more natural to me that putting the partitions under the

> > > >>> top-level BLK device, so that BLK remains a 'terminal' device.

> > > >>>

> > > >>> The partition uclass is different from BLK, of course. It could

> > > >>> contain information about the partition such as its partition number

> > > >>> and UUID.

>

> Yeah, but there is always 1-to-1 mapping between a partition and

> a block (for a partition), so I still wonder whether it makes sense

> to model partitions in the way above.

>

> Alternatively, the following hierarchy also makes some sense.

> (This is not what I have in my RFC though.)

> - MMC

> |- BLK (whole disk with part=0)

> |- BLK (partition 1)

> |- BLK (partition 2)

> |- BLK (partition 3)

>

> or

>

> - MMC

> |- DISK (whole disk)

> ||- BLK (partition 0)

> ||- BLK (partition 1)

> ||- BLK (partition 2)

> ||- BLK (partition 3)

>

> Here

> MMC: provides read/write operations (via blk_ops)

> DISK: holds a geometry of a whole disk and other info

> BLK: partition info (+ blk_ops + geo) (part=0 means a while disk)


Where does this leave hwpart? Are we giving up on that?

Both of these make some sense to me, although I'm not sure what the
second one buys us. Can you explain that? Is it to deal with hwpart?

The name 'disk' is pretty awful though, these days.

If we want to iterate through all the partition tables across all
devices, we could do that with a partition uclass. We could support
different types of partition (s/w and h/w) with the same device
driver.

I think conceptually it is cleaner to have a partition uclass but I do
agree that it corresponds 100% to BLK, so maybe there is little value
in practice. But which device holds the partition table in its
dev_get_priv()?

>

> > > >> Do you mean hardware partition here? Otherwise I would not know what BLK

> > > >> should model.

> > > >

> > > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > > should just be a block device.

> > >

> > > That is fine. But this implies that a software partition is the child of

> > > a block partition and not the other way round. So the tree should like:

> > >

> > > MMC

> > > |- BLK (user hardware partition)

> > > ||- PARTITION 1 (software partition)

> > > ||- PARTITION 2 (software partition)

> > > |...

> > > ||- PARTITION n (software partition)

> > > |- BLK (rpmb hardware partition)

> > > |- BLK (boot0 hardware partition)

> > > |- BLK (boot1 hardware partition)

> >

> > I presume you meant to include a BLK device under each PARTITION?

> >

> > But anyway, I was more thinking of this:

> >

> > MMC

> > | HWPARTITION rpmb

> > || BLK whole rpmb

> > || PARTITION 1

> > ||| BLK

> > || PARTITION 2

> > ||| BLK

> > || PARTITION 3

>

> Do we have any reason to model a RPMB partition as a block device?

> For linux, at least, mmcblkrpmb looks to be a character device.

>

> > ||| BLK

> > | HWPARTITION boot0

> > || BLK

> > (maybe have PARTITION in here too?

>

> I don't know how boot partitions are used on a production system.

> It's unlikely to have partitions on them given the purpose of "boot"

> partitions?


That's true. So likely they will not be used.

>

> > | HWPARTITION boot1

> > (maybe have PARTITION in here too?

> > || BLK

> >

> > >

> > > >

> > > > I don't see any difference between a partition and a hardware

> > > > partition. We presumably end up with a hierarchy though. Do we need a

> > > > HWPARTITION uclass so we can handle the hardware partitions

> > > > differently?

> > >

> > > Software partitions are defined and discovered via partition tables.

> > > Hardware partitions are defined in a hardware specific way.

> > >

> > > All software partitions map to HD() device tree nodes in UEFI.

> > > An MMC device maps to an eMMC() node

> > > MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

> > > do the same in U-Boot.

> > > An SD-card maps to an SD() node.

> > > An NVMe namespace maps to a NVMe() node.

> > > An SCSI LUN maps to a Scsi() node.

> > > SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

> >

> > I'm not quite sure about the terminology here. I'm not even talking

> > about UEFI, really, just how best to model this stuff in U-Boot.

>

> In UEFI world, each efi_disk has its own device path to identify the device.

> For example, here is a text representation of device path for a scsi disk

> partition:

>   /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a)

>

> which is set to be created from a corresponding udevice (more strictly

> blkc_desc + part).

>

> So the issue Heinrich raised here is a matter of implementation of

> this conversion (software partitions, and SCSI channels?) as well as

> a modeling for some device type on U-Boot, i.e. MMC hardware partitions.


Yes I see that. It's just that we should get our house in order first,
since these discussions didn't happen when the EFI layer was written 6
years ago. If we have a good model for partitions (not just block
devices) in U-Boot then it should be easier to map EFI onto it.

Regards,
Simon


>

> -Takahiro Akashi

>

> > In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

> > right? I'm a little worried it is not modelled correctly. After all,

> > what is the parent of a SCSI device?

> >

> > >

> > > The simple file protocol is only provided by HD() nodes and not by nodes

> > > representing hardware partitions. If the whole hardware partition is

> > > formatted as a file system you would still create a HD() node with

> > > partition number 0.

> >

> > Regards,

> > Simon

> ---

> >

> > >

> > > When it comes to UEFI, I hope we can currently support hw partitions

> > > in this way:

> > >   => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""

> > > (".1" is a key, I have never tried this syntax though.)

> > >

> > > But probably its device path won't be properly formatted

> > > as expected as Heinrich suggested.

> > >

> > > -Takahiro Akashi

> > >

> > >

> > > > In terms of modeling, this is akin to how if you use a USB card reader

> > > > that supports 4 different form-factor cards, you can end up with 4

> > > > different devices showing up in Linux (if you have one of the nice card

> > > > readers that supports multiple cards at once).

> > > >

> > > > --

> > > > Tom

> > >

> > >

> >

> > Regards,

> > Simon

AKASHI Takahiro Oct. 28, 2021, 8:52 a.m. UTC | #20

Hi Simon,

I'd like to resume this discussion.

On Thu, Oct 14, 2021 at 02:55:36PM -0600, Simon Glass wrote:
> Hi Takahiro,

> 

> On Thu, 14 Oct 2021 at 02:03, AKASHI Takahiro

> <takahiro.akashi@linaro.org> wrote:

> >

> > Simon,

> >

> > On Wed, Oct 13, 2021 at 12:05:58PM -0600, Simon Glass wrote:

> > > Hi Takahiro,

> > >

> > > On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro

> > > <takahiro.akashi@linaro.org> wrote:

> > > >

> > > > On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:

> > > > > On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

> > > > > > Hi Heinrich,

> > > > > >

> > > > > > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > > > > > >

> > > > > > >

> > > > > > >

> > > > > > > On 10/11/21 16:54, Simon Glass wrote:

> > > > > > > > Hi Takahiro,

> > > > > > > >

> > > > > > > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> > > > > > > > <takahiro.akashi@linaro.org> wrote:

> > > > > > > >>

> > > > > > > >> Heinrich,

> > > > > > > >>

> > > > > > > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> > > > > > > >>>

> > > > > > > >>>

> > > > > > > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> > > > > > > >>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> > > > > > > >>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> > > > > > > >>>>>>

> > > > > > > >>>>>>

> > > > > > > >>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> > > > > > > >>>>>>> UCLASS_PARTITION device will be created as a child node of

> > > > > > > >>>>>>> UCLASS_BLK device.

> > > > > > > >>>>>>>

> > > > > > > >>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> > > > > > > >>>>>>> ---

> > > > > > > >>>>>>>     drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> > > > > > > >>>>>>>     include/blk.h              |   9 +++

> > > > > > > >>>>>>>     include/dm/uclass-id.h     |   1 +

> > > > > > > >>>>>>>     3 files changed, 121 insertions(+)

> > > > > > > >>>>>>>

> > > > > > > >>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> > > > > > > >>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> > > > > > > >>>>>>> --- a/drivers/block/blk-uclass.c

> > > > > > > >>>>>>> +++ b/drivers/block/blk-uclass.c

> > > > > > > >>>>>>> @@ -12,6 +12,7 @@

> > > > > > > >>>>>>>     #include <log.h>

> > > > > > > >>>>>>>     #include <malloc.h>

> > > > > > > >>>>>>>     #include <part.h>

> > > > > > > >>>>>>> +#include <string.h>

> > > > > > > >>>>>>>     #include <dm/device-internal.h>

> > > > > > > >>>>>>>     #include <dm/lists.h>

> > > > > > > >>>>>>>     #include <dm/uclass-internal.h>

> > > > > > > >>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> > > > > > > >>>>>>>        return 0;

> > > > > > > >>>>>>>     }

> > > > > > > >>>>>>>

> > > > > > > >>>>>>> +int blk_create_partitions(struct udevice *parent)

> > > > > > > >>>>>>> +{

> > > > > > > >>>>>>> +     int part, count;

> > > > > > > >>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > > > >>>>>>> +     struct disk_partition info;

> > > > > > > >>>>>>> +     struct disk_part *part_data;

> > > > > > > >>>>>>> +     char devname[32];

> > > > > > > >>>>>>> +     struct udevice *dev;

> > > > > > > >>>>>>> +     int ret;

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> > > > > > > >>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> > > > > > > >>>>>>> +             return 0;

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +     /* Add devices for each partition */

> > > > > > > >>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> > > > > > > >>>>>>> +             if (part_get_info(desc, part, &info))

> > > > > > > >>>>>>> +                     continue;

> > > > > > > >>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> > > > > > > >>>>>>> +                      part);

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> > > > > > > >>>>>>> +                                      strdup(devname), &dev);

> > > > > > > >>>>>>> +             if (ret)

> > > > > > > >>>>>>> +                     return ret;

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +             part_data = dev_get_uclass_plat(dev);

> > > > > > > >>>>>>> +             part_data->partnum = part;

> > > > > > > >>>>>>> +             part_data->gpt_part_info = info;

> > > > > > > >>>>>>> +             count++;

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +             device_probe(dev);

> > > > > > > >>>>>>> +     }

> > > > > > > >>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +     return 0;

> > > > > > > >>>>>>> +}

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>>     static int blk_post_probe(struct udevice *dev)

> > > > > > > >>>>>>>     {

> > > > > > > >>>>>>>        if (IS_ENABLED(CONFIG_PARTITIONS) &&

> > > > > > > >>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> > > > > > > >>>>>>>        .post_probe     = blk_post_probe,

> > > > > > > >>>>>>>        .per_device_plat_auto   = sizeof(struct blk_desc),

> > > > > > > >>>>>>>     };

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> > > > > > > >>>>>>> +                        lbaint_t blkcnt, void *buffer)

> > > > > > > >>>>>>> +{

> > > > > > > >>>>>>> +     struct udevice *parent;

> > > > > > > >>>>>>> +     struct disk_part *part;

> > > > > > > >>>>>>> +     const struct blk_ops *ops;

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +     parent = dev_get_parent(dev);

> > > > > > > >>>>>>

> > > > > > > >>>>>> What device type will the parent have if it is a eMMC hardware partition?

> > > > > > > >>>>>>

> > > > > > > >>>>>>> +     ops = blk_get_ops(parent);

> > > > > > > >>>>>>> +     if (!ops->read)

> > > > > > > >>>>>>> +             return -ENOSYS;

> > > > > > > >>>>>>> +

> > > > > > > >>>>>>> +     part = dev_get_uclass_plat(dev);

> > > > > > > >>>>>>

> > > > > > > >>>>>> You should check that we do not access the block device past the

> > > > > > > >>>>>> partition end:

> > > > > > > >>>>>

> > > > > > > >>>>> Yes, I will fix all of checks.

> > > > > > > >>>>>

> > > > > > > >>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> > > > > > > >>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> > > > > > > >>>>>>          return -EFAULT.

> > > > > > > >>>>>>

> > > > > > > >>>>>>> +     start += part->gpt_part_info.start;

> > > > > > > >>>>

> > > > > > > >>>> A better solution is:

> > > > > > > >>>>           if (start >= part->gpt_part_info.size)

> > > > > > > >>>>                   return 0;

> > > > > > > >>>>

> > > > > > > >>>>           if ((start + blkcnt) > part->gpt_part_info.size)

> > > > > > > >>>>                   blkcnt = part->gpt_part_info.size - start;

> > > > > > > >>>>           start += part->gpt_part_info.start;

> > > > > > > >>>> instead of returning -EFAULT.

> > > > > > > >>>> (note that start and blkcnt are in "block".)

> > > > > > > >>>

> > > > > > > >>> What is your motivation to support an illegal access?

> > > > > > > >>>

> > > > > > > >>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> > > > > > > >>> ReadBlocks() and WriteBlocks() services must return

> > > > > > > >>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> > > > > > > >>> valid.

> > > > > > > >>

> > > > > > > >> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> > > > > > > >> and that if the starting block is out of partition region, we should

> > > > > > > >> return an error (and if not, we still want to trim IO request to fit

> > > > > > > >> into partition size as other OS's API like linux does).

> > > > > > > >> Do you think it's incorrect?

> > > > > > > >

> > > > > > > > [..]

> > > > > > > >

> > > > > > > > Related to this patch I think that the partition type should be really

> > > > > > > > be a child of the media device:

> > > > > > > >

> > > > > > > > - MMC

> > > > > > > >      |- BLK

> > > > > > > >      |- PARTITION

> > > > > > > >         |- BLK

> > > > > > > >      |- PARTITION

> > > > > > > >         |- BLK

> > > > > > > >      |- PARTITION

> > > > > > > >         |- BLK

> > > > > > > >

> > > > > > > > It seems more natural to me that putting the partitions under the

> > > > > > > > top-level BLK device, so that BLK remains a 'terminal' device.

> > > > > > > >

> > > > > > > > The partition uclass is different from BLK, of course. It could

> > > > > > > > contain information about the partition such as its partition number

> > > > > > > > and UUID.

> > > > > > >

> > > > > > > Do you mean hardware partition here? Otherwise I would not know what BLK

> > > > > > > should model.

> > > > > >

> > > > > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > > > > should just be a block device.

> > > > > >

> > > > > > I don't see any difference between a partition and a hardware

> > > > > > partition. We presumably end up with a hierarchy though. Do we need a

> > > > > > HWPARTITION uclass so we can handle the hardware partitions

> > > > > > differently?

> > > > >

> > > > > Note that for eMMC devices, hardware partitions are different from

> > > > > partition-table partitions.  If you boot a system with an eMMC device up

> > > > > in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

> > > > > mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

> > > > > U-Boot in that you can access each of these with 'mmc dev N M' where M

> > > > > defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

> > > > > and 3 is the rpmb area.  The 'mmc' command also allows, when possible

> > > > > and implemented, configuring these partitions, again to the extent

> > > > > allowed, documented and implemented.

> > > >

> > > > Thank you. That is exactly what I tried to mention in my reply

> > > > at "part: call part_init() in blk_get_device_by_str() only for MMC"

> > >

> > > OK so it sounds like we agree that hwpartition and partition are

> > > different things.

> >

> > Yes.

> > Please note, IIUC, that

> > * MMC hw partitions on a device are mapped to one udevice, differentiating

> >   them by blk_desc->hwpart.

> > * Each NVME namespace on a device is mapped to a different udevice with

> >   a different blk_desc->devnum (and nvme_dev->ns_id).

> > * Each UFS partition (or which is, I suppose, equivalent to scsi LUN) on

> >   a device is mapped to a different udevice with a different blk_desc->devnum

> >   (and blk_desc->lun).

> >

> > So even though those type of devices have some kind of hardware partitions,

> > they are modelled differently in U-Boot.

> > (Obviously, I might be wrong here as I'm not quite familiar yet.)

> >

> > > >

> > > > ---8<---

> > > > # On the other hand, we have to explicitly switch "hw partitions"

> > > > # with blk_select_hwpart_devnum() on MMC devices even though we use

> > > > # the *same* udevice(blk_desc).

> > > > --->8---

> > > >

> > > > The problem with the current U-Boot driver model is that all of "mmcblkN,

> > > > mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same

> > > > udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()

> > > > to distinguish them.

> > >

> > > Here's our chance to rethink this. What should the device hierarchy be

> > > for an MMC device? I made a proposal further up the thread.

> >

> > Well,

> >

> > On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:

> > > On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >

> > > > >>> [..]

> >

> > > > >>> Related to this patch I think that the partition type should be really

> > > > >>> be a child of the media device:

> > > > >>>

> > > > >>> - MMC

> > > > >>>       |- BLK

> > > > >>>       |- PARTITION

> > > > >>>          |- BLK

> > > > >>>       |- PARTITION

> > > > >>>          |- BLK

> > > > >>>       |- PARTITION

> > > > >>>          |- BLK

> > > > >>>

> > > > >>> It seems more natural to me that putting the partitions under the

> > > > >>> top-level BLK device, so that BLK remains a 'terminal' device.

> > > > >>>

> > > > >>> The partition uclass is different from BLK, of course. It could

> > > > >>> contain information about the partition such as its partition number

> > > > >>> and UUID.

> >

> > Yeah, but there is always 1-to-1 mapping between a partition and

> > a block (for a partition), so I still wonder whether it makes sense

> > to model partitions in the way above.

> >

> > Alternatively, the following hierarchy also makes some sense.

> > (This is not what I have in my RFC though.)

> > - MMC

> > |- BLK (whole disk with part=0)

> > |- BLK (partition 1)

> > |- BLK (partition 2)

> > |- BLK (partition 3)

> >

> > or

> >

> > - MMC

> > |- DISK (whole disk)

> > ||- BLK (partition 0)

> > ||- BLK (partition 1)

> > ||- BLK (partition 2)

> > ||- BLK (partition 3)

> >

> > Here

> > MMC: provides read/write operations (via blk_ops)

> > DISK: holds a geometry of a whole disk and other info

> > BLK: partition info (+ blk_ops + geo) (part=0 means a while disk)

> 

> Where does this leave hwpart? Are we giving up on that?


No, not at all :)
I'm thinking of dealing with hw partitions as independent BLK devices.
This is already true for NVME (namespaces) and UFS (LUNs)(not sure, though).
For MMC, struct blk_desc has 'hwpart' field to indicate a hw partition and
Apparently, it will be easy to have different BLK devices with
different hwpart's.
(Then we will have to add a probe function for hw partitions.)

> Both of these make some sense to me, although I'm not sure what the

> second one buys us. Can you explain that? Is it to deal with hwpart?


So,

- MMC (bus controller)
|- BLK (device/hw partition:user data)
||- DISK (partition 0 == a whole device)
||- DISK (partition 1)
||- DISK (partition 2)
||- DISK (partition 3)
|- BLK (device/hw partition:boot0)
||- DISK (partition 0 == a whole device)
|- BLK (device/hw partition:boot0)
||- DISK (partition 0 == a whole device)
|- BLK (device/hw partition:rpmb) -- this is NOT a 'block' device, though.
||- DISK (partition 0 == a whole device)

    MMC: provides access methods (via blk_ops)
    BLK: represents a physical device and holds a geometry of the whole
         device and other info
    DISK: block-access entities with partition info
          (part=0 means a while disk)

    (MMC, BLK are of current implementation.)

To avoid confusion, UCLASS_PARTITION is renamed to UCLASS_DISK with
a little modified semantics. The name can be seen aligned with 'disk/'
directory for sw partitions.
Partition 0 expectedly behaves in the same way as an existing BLK.

With this scheme, I assume that we should thoroughly use new interfaces
    dev_read(struct udevice *dev, lbaint_t start,
                lbaint_t blkcnt, void *buffer);
    dev_write(struct udevice *dev, lbaint_t start,
                lbaint_t blkcnt, void *buffer);
for block-level operations with DISK devices.
                                ^^^^

The legacy interfaces with blk_desc's in BLK devices:
    blk_dread(struct blk_desc *block_dev, lbaint_t start,
                lbaint_t blkcnt, void *buffer)
    blk_dwrite(struct blk_desc *block_dev, lbaint_t start,
                lbaint_t blkcnt, void *buffer)l
are to be retained, at least, during the transition period
(mostly for existing filesystems and commands).

> The name 'disk' is pretty awful though, these days.


Think so?
Honestly, I'd like to rename BLK to DISK (or BLK_MEDIA) and
rename DISK to BLK to reflect their rolls :)

> If we want to iterate through all the partition tables across all

> devices, we could do that with a partition uclass. We could support

> different types of partition (s/w and h/w) with the same device

> driver.

> 

> I think conceptually it is cleaner to have a partition uclass but I do

> agree that it corresponds 100% to BLK, so maybe there is little value

> in practice. But which device holds the partition table in its

> dev_get_priv()?


Do you think that some device should have "partition table" info
in its inner data structure of udevice?
BLK-DISK relationship can represent a partition table in some way,
and MMC-BLK can model hw partitioning.

Thanks,
-Takahiro Akashi

> >

> > > > >> Do you mean hardware partition here? Otherwise I would not know what BLK

> > > > >> should model.

> > > > >

> > > > > I mean that (I think) we should not use BLK to model partitions. A BLK

> > > > > should just be a block device.

> > > >

> > > > That is fine. But this implies that a software partition is the child of

> > > > a block partition and not the other way round. So the tree should like:

> > > >

> > > > MMC

> > > > |- BLK (user hardware partition)

> > > > ||- PARTITION 1 (software partition)

> > > > ||- PARTITION 2 (software partition)

> > > > |...

> > > > ||- PARTITION n (software partition)

> > > > |- BLK (rpmb hardware partition)

> > > > |- BLK (boot0 hardware partition)

> > > > |- BLK (boot1 hardware partition)

> > >

> > > I presume you meant to include a BLK device under each PARTITION?

> > >

> > > But anyway, I was more thinking of this:

> > >

> > > MMC

> > > | HWPARTITION rpmb

> > > || BLK whole rpmb

> > > || PARTITION 1

> > > ||| BLK

> > > || PARTITION 2

> > > ||| BLK

> > > || PARTITION 3

> >

> > Do we have any reason to model a RPMB partition as a block device?

> > For linux, at least, mmcblkrpmb looks to be a character device.

> >

> > > ||| BLK

> > > | HWPARTITION boot0

> > > || BLK

> > > (maybe have PARTITION in here too?

> >

> > I don't know how boot partitions are used on a production system.

> > It's unlikely to have partitions on them given the purpose of "boot"

> > partitions?

> 

> That's true. So likely they will not be used.

> 

> >

> > > | HWPARTITION boot1

> > > (maybe have PARTITION in here too?

> > > || BLK

> > >

> > > >

> > > > >

> > > > > I don't see any difference between a partition and a hardware

> > > > > partition. We presumably end up with a hierarchy though. Do we need a

> > > > > HWPARTITION uclass so we can handle the hardware partitions

> > > > > differently?

> > > >

> > > > Software partitions are defined and discovered via partition tables.

> > > > Hardware partitions are defined in a hardware specific way.

> > > >

> > > > All software partitions map to HD() device tree nodes in UEFI.

> > > > An MMC device maps to an eMMC() node

> > > > MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

> > > > do the same in U-Boot.

> > > > An SD-card maps to an SD() node.

> > > > An NVMe namespace maps to a NVMe() node.

> > > > An SCSI LUN maps to a Scsi() node.

> > > > SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

> > >

> > > I'm not quite sure about the terminology here. I'm not even talking

> > > about UEFI, really, just how best to model this stuff in U-Boot.

> >

> > In UEFI world, each efi_disk has its own device path to identify the device.

> > For example, here is a text representation of device path for a scsi disk

> > partition:

> >   /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a)

> >

> > which is set to be created from a corresponding udevice (more strictly

> > blkc_desc + part).

> >

> > So the issue Heinrich raised here is a matter of implementation of

> > this conversion (software partitions, and SCSI channels?) as well as

> > a modeling for some device type on U-Boot, i.e. MMC hardware partitions.

> 

> Yes I see that. It's just that we should get our house in order first,

> since these discussions didn't happen when the EFI layer was written 6

> years ago. If we have a good model for partitions (not just block

> devices) in U-Boot then it should be easier to map EFI onto it.

> 

> Regards,

> Simon

> 

> 

> >

> > -Takahiro Akashi

> >

> > > In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

> > > right? I'm a little worried it is not modelled correctly. After all,

> > > what is the parent of a SCSI device?

> > >

> > > >

> > > > The simple file protocol is only provided by HD() nodes and not by nodes

> > > > representing hardware partitions. If the whole hardware partition is

> > > > formatted as a file system you would still create a HD() node with

> > > > partition number 0.

> > >

> > > Regards,

> > > Simon

> > ---

> > >

> > > >

> > > > When it comes to UEFI, I hope we can currently support hw partitions

> > > > in this way:

> > > >   => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""

> > > > (".1" is a key, I have never tried this syntax though.)

> > > >

> > > > But probably its device path won't be properly formatted

> > > > as expected as Heinrich suggested.

> > > >

> > > > -Takahiro Akashi

> > > >

> > > >

> > > > > In terms of modeling, this is akin to how if you use a USB card reader

> > > > > that supports 4 different form-factor cards, you can end up with 4

> > > > > different devices showing up in Linux (if you have one of the nice card

> > > > > readers that supports multiple cards at once).

> > > > >

> > > > > --

> > > > > Tom

> > > >

> > > >

> > >

> > > Regards,

> > > Simon

Heinrich Schuchardt Oct. 28, 2021, 10:42 a.m. UTC | #21

On 10/28/21 10:52, AKASHI Takahiro wrote:
> Hi Simon,

>

> I'd like to resume this discussion.

>

> On Thu, Oct 14, 2021 at 02:55:36PM -0600, Simon Glass wrote:

>> Hi Takahiro,

>>

>> On Thu, 14 Oct 2021 at 02:03, AKASHI Takahiro

>> <takahiro.akashi@linaro.org> wrote:

>>>

>>> Simon,

>>>

>>> On Wed, Oct 13, 2021 at 12:05:58PM -0600, Simon Glass wrote:

>>>> Hi Takahiro,

>>>>

>>>> On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro

>>>> <takahiro.akashi@linaro.org> wrote:

>>>>>

>>>>> On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:

>>>>>> On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

>>>>>>> Hi Heinrich,

>>>>>>>

>>>>>>> On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

>>>>>>>>

>>>>>>>>

>>>>>>>>

>>>>>>>> On 10/11/21 16:54, Simon Glass wrote:

>>>>>>>>> Hi Takahiro,

>>>>>>>>>

>>>>>>>>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

>>>>>>>>> <takahiro.akashi@linaro.org> wrote:

>>>>>>>>>>

>>>>>>>>>> Heinrich,

>>>>>>>>>>

>>>>>>>>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

>>>>>>>>>>>

>>>>>>>>>>>

>>>>>>>>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

>>>>>>>>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

>>>>>>>>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

>>>>>>>>>>>>>>

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

>>>>>>>>>>>>>>> UCLASS_PARTITION device will be created as a child node of

>>>>>>>>>>>>>>> UCLASS_BLK device.

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

>>>>>>>>>>>>>>> ---

>>>>>>>>>>>>>>>      drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

>>>>>>>>>>>>>>>      include/blk.h              |   9 +++

>>>>>>>>>>>>>>>      include/dm/uclass-id.h     |   1 +

>>>>>>>>>>>>>>>      3 files changed, 121 insertions(+)

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

>>>>>>>>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

>>>>>>>>>>>>>>> --- a/drivers/block/blk-uclass.c

>>>>>>>>>>>>>>> +++ b/drivers/block/blk-uclass.c

>>>>>>>>>>>>>>> @@ -12,6 +12,7 @@

>>>>>>>>>>>>>>>      #include <log.h>

>>>>>>>>>>>>>>>      #include <malloc.h>

>>>>>>>>>>>>>>>      #include <part.h>

>>>>>>>>>>>>>>> +#include <string.h>

>>>>>>>>>>>>>>>      #include <dm/device-internal.h>

>>>>>>>>>>>>>>>      #include <dm/lists.h>

>>>>>>>>>>>>>>>      #include <dm/uclass-internal.h>

>>>>>>>>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

>>>>>>>>>>>>>>>         return 0;

>>>>>>>>>>>>>>>      }

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> +int blk_create_partitions(struct udevice *parent)

>>>>>>>>>>>>>>> +{

>>>>>>>>>>>>>>> +     int part, count;

>>>>>>>>>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>>>>>>>>>>>>> +     struct disk_partition info;

>>>>>>>>>>>>>>> +     struct disk_part *part_data;

>>>>>>>>>>>>>>> +     char devname[32];

>>>>>>>>>>>>>>> +     struct udevice *dev;

>>>>>>>>>>>>>>> +     int ret;

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

>>>>>>>>>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

>>>>>>>>>>>>>>> +             return 0;

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +     /* Add devices for each partition */

>>>>>>>>>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

>>>>>>>>>>>>>>> +             if (part_get_info(desc, part, &info))

>>>>>>>>>>>>>>> +                     continue;

>>>>>>>>>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

>>>>>>>>>>>>>>> +                      part);

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

>>>>>>>>>>>>>>> +                                      strdup(devname), &dev);

>>>>>>>>>>>>>>> +             if (ret)

>>>>>>>>>>>>>>> +                     return ret;

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +             part_data = dev_get_uclass_plat(dev);

>>>>>>>>>>>>>>> +             part_data->partnum = part;

>>>>>>>>>>>>>>> +             part_data->gpt_part_info = info;

>>>>>>>>>>>>>>> +             count++;

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +             device_probe(dev);

>>>>>>>>>>>>>>> +     }

>>>>>>>>>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +     return 0;

>>>>>>>>>>>>>>> +}

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>>      static int blk_post_probe(struct udevice *dev)

>>>>>>>>>>>>>>>      {

>>>>>>>>>>>>>>>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

>>>>>>>>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

>>>>>>>>>>>>>>>         .post_probe     = blk_post_probe,

>>>>>>>>>>>>>>>         .per_device_plat_auto   = sizeof(struct blk_desc),

>>>>>>>>>>>>>>>      };

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

>>>>>>>>>>>>>>> +                        lbaint_t blkcnt, void *buffer)

>>>>>>>>>>>>>>> +{

>>>>>>>>>>>>>>> +     struct udevice *parent;

>>>>>>>>>>>>>>> +     struct disk_part *part;

>>>>>>>>>>>>>>> +     const struct blk_ops *ops;

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +     parent = dev_get_parent(dev);

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> What device type will the parent have if it is a eMMC hardware partition?

>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> +     ops = blk_get_ops(parent);

>>>>>>>>>>>>>>> +     if (!ops->read)

>>>>>>>>>>>>>>> +             return -ENOSYS;

>>>>>>>>>>>>>>> +

>>>>>>>>>>>>>>> +     part = dev_get_uclass_plat(dev);

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> You should check that we do not access the block device past the

>>>>>>>>>>>>>> partition end:

>>>>>>>>>>>>>

>>>>>>>>>>>>> Yes, I will fix all of checks.

>>>>>>>>>>>>>

>>>>>>>>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

>>>>>>>>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

>>>>>>>>>>>>>>           return -EFAULT.

>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> +     start += part->gpt_part_info.start;

>>>>>>>>>>>>

>>>>>>>>>>>> A better solution is:

>>>>>>>>>>>>            if (start >= part->gpt_part_info.size)

>>>>>>>>>>>>                    return 0;

>>>>>>>>>>>>

>>>>>>>>>>>>            if ((start + blkcnt) > part->gpt_part_info.size)

>>>>>>>>>>>>                    blkcnt = part->gpt_part_info.size - start;

>>>>>>>>>>>>            start += part->gpt_part_info.start;

>>>>>>>>>>>> instead of returning -EFAULT.

>>>>>>>>>>>> (note that start and blkcnt are in "block".)

>>>>>>>>>>>

>>>>>>>>>>> What is your motivation to support an illegal access?

>>>>>>>>>>>

>>>>>>>>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

>>>>>>>>>>> ReadBlocks() and WriteBlocks() services must return

>>>>>>>>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

>>>>>>>>>>> valid.

>>>>>>>>>>

>>>>>>>>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

>>>>>>>>>> and that if the starting block is out of partition region, we should

>>>>>>>>>> return an error (and if not, we still want to trim IO request to fit

>>>>>>>>>> into partition size as other OS's API like linux does).

>>>>>>>>>> Do you think it's incorrect?

>>>>>>>>>

>>>>>>>>> [..]

>>>>>>>>>

>>>>>>>>> Related to this patch I think that the partition type should be really

>>>>>>>>> be a child of the media device:

>>>>>>>>>

>>>>>>>>> - MMC

>>>>>>>>>       |- BLK

>>>>>>>>>       |- PARTITION

>>>>>>>>>          |- BLK

>>>>>>>>>       |- PARTITION

>>>>>>>>>          |- BLK

>>>>>>>>>       |- PARTITION

>>>>>>>>>          |- BLK

>>>>>>>>>

>>>>>>>>> It seems more natural to me that putting the partitions under the

>>>>>>>>> top-level BLK device, so that BLK remains a 'terminal' device.

>>>>>>>>>

>>>>>>>>> The partition uclass is different from BLK, of course. It could

>>>>>>>>> contain information about the partition such as its partition number

>>>>>>>>> and UUID.

>>>>>>>>

>>>>>>>> Do you mean hardware partition here? Otherwise I would not know what BLK

>>>>>>>> should model.

>>>>>>>

>>>>>>> I mean that (I think) we should not use BLK to model partitions. A BLK

>>>>>>> should just be a block device.

>>>>>>>

>>>>>>> I don't see any difference between a partition and a hardware

>>>>>>> partition. We presumably end up with a hierarchy though. Do we need a

>>>>>>> HWPARTITION uclass so we can handle the hardware partitions

>>>>>>> differently?

>>>>>>

>>>>>> Note that for eMMC devices, hardware partitions are different from

>>>>>> partition-table partitions.  If you boot a system with an eMMC device up

>>>>>> in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

>>>>>> mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

>>>>>> U-Boot in that you can access each of these with 'mmc dev N M' where M

>>>>>> defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

>>>>>> and 3 is the rpmb area.  The 'mmc' command also allows, when possible

>>>>>> and implemented, configuring these partitions, again to the extent

>>>>>> allowed, documented and implemented.

>>>>>

>>>>> Thank you. That is exactly what I tried to mention in my reply

>>>>> at "part: call part_init() in blk_get_device_by_str() only for MMC"

>>>>

>>>> OK so it sounds like we agree that hwpartition and partition are

>>>> different things.

>>>

>>> Yes.

>>> Please note, IIUC, that

>>> * MMC hw partitions on a device are mapped to one udevice, differentiating

>>>    them by blk_desc->hwpart.

>>> * Each NVME namespace on a device is mapped to a different udevice with

>>>    a different blk_desc->devnum (and nvme_dev->ns_id).

>>> * Each UFS partition (or which is, I suppose, equivalent to scsi LUN) on

>>>    a device is mapped to a different udevice with a different blk_desc->devnum

>>>    (and blk_desc->lun).

>>>

>>> So even though those type of devices have some kind of hardware partitions,

>>> they are modelled differently in U-Boot.

>>> (Obviously, I might be wrong here as I'm not quite familiar yet.)

>>>

>>>>>

>>>>> ---8<---

>>>>> # On the other hand, we have to explicitly switch "hw partitions"

>>>>> # with blk_select_hwpart_devnum() on MMC devices even though we use

>>>>> # the *same* udevice(blk_desc).

>>>>> --->8---

>>>>>

>>>>> The problem with the current U-Boot driver model is that all of "mmcblkN,

>>>>> mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same

>>>>> udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()

>>>>> to distinguish them.

>>>>

>>>> Here's our chance to rethink this. What should the device hierarchy be

>>>> for an MMC device? I made a proposal further up the thread.

>>>

>>> Well,

>>>

>>> On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:

>>>> On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

>>>

>>>>>>>> [..]

>>>

>>>>>>>> Related to this patch I think that the partition type should be really

>>>>>>>> be a child of the media device:

>>>>>>>>

>>>>>>>> - MMC

>>>>>>>>        |- BLK

>>>>>>>>        |- PARTITION

>>>>>>>>           |- BLK

>>>>>>>>        |- PARTITION

>>>>>>>>           |- BLK

>>>>>>>>        |- PARTITION

>>>>>>>>           |- BLK

>>>>>>>>

>>>>>>>> It seems more natural to me that putting the partitions under the

>>>>>>>> top-level BLK device, so that BLK remains a 'terminal' device.

>>>>>>>>

>>>>>>>> The partition uclass is different from BLK, of course. It could

>>>>>>>> contain information about the partition such as its partition number

>>>>>>>> and UUID.

>>>

>>> Yeah, but there is always 1-to-1 mapping between a partition and

>>> a block (for a partition), so I still wonder whether it makes sense

>>> to model partitions in the way above.

>>>

>>> Alternatively, the following hierarchy also makes some sense.

>>> (This is not what I have in my RFC though.)

>>> - MMC

>>> |- BLK (whole disk with part=0)

>>> |- BLK (partition 1)

>>> |- BLK (partition 2)

>>> |- BLK (partition 3)

>>>

>>> or

>>>

>>> - MMC

>>> |- DISK (whole disk)

>>> ||- BLK (partition 0)

>>> ||- BLK (partition 1)

>>> ||- BLK (partition 2)

>>> ||- BLK (partition 3)

>>>

>>> Here

>>> MMC: provides read/write operations (via blk_ops)

>>> DISK: holds a geometry of a whole disk and other info

>>> BLK: partition info (+ blk_ops + geo) (part=0 means a while disk)

>>

>> Where does this leave hwpart? Are we giving up on that?

>

> No, not at all :)

> I'm thinking of dealing with hw partitions as independent BLK devices.

> This is already true for NVME (namespaces) and UFS (LUNs)(not sure, though).

> For MMC, struct blk_desc has 'hwpart' field to indicate a hw partition and

> Apparently, it will be easy to have different BLK devices with

> different hwpart's.

> (Then we will have to add a probe function for hw partitions.)

>

>> Both of these make some sense to me, although I'm not sure what the

>> second one buys us. Can you explain that? Is it to deal with hwpart?

>

> So,

>

> - MMC (bus controller)

> |- BLK (device/hw partition:user data)

> ||- DISK (partition 0 == a whole device)

> ||- DISK (partition 1)

> ||- DISK (partition 2)

> ||- DISK (partition 3)

> |- BLK (device/hw partition:boot0)

> ||- DISK (partition 0 == a whole device)

> |- BLK (device/hw partition:boot0)

> ||- DISK (partition 0 == a whole device)

> |- BLK (device/hw partition:rpmb) -- this is NOT a 'block' device, though.

> ||- DISK (partition 0 == a whole device)

>

>      MMC: provides access methods (via blk_ops)

>      BLK: represents a physical device and holds a geometry of the whole

>           device and other info

>      DISK: block-access entities with partition info

>            (part=0 means a while disk)

>

>      (MMC, BLK are of current implementation.)


Could you, please, add the path from the root, devices without hardware
partitions (e.g. IDE, SATA), and devices with LUNs (SCSI) to the tree.
Please, also add the device-tree nodes. This will allow us to see the
whole picture, and observe how UEFI device paths and the DM tree are
matched.

>

> To avoid confusion, UCLASS_PARTITION is renamed to UCLASS_DISK with

> a little modified semantics. The name can be seen aligned with 'disk/'


Renaming UCLASS_PARTITION to UCLASS_DISK is very confusing. A disk to me
is a block device which may have partitions.

> directory for sw partitions.

> Partition 0 expectedly behaves in the same way as an existing BLK.


It will expose block IO and it may expose a file system.
The same is valid for the true partitions.

A block device does not expose a file system.

So partition 0 just behaves at it always did in U-Boot.


>

> With this scheme, I assume that we should thoroughly use new interfaces

>      dev_read(struct udevice *dev, lbaint_t start,

>                  lbaint_t blkcnt, void *buffer);

>      dev_write(struct udevice *dev, lbaint_t start,

>                  lbaint_t blkcnt, void *buffer);

> for block-level operations with DISK devices.

>                                  ^^^^

>

> The legacy interfaces with blk_desc's in BLK devices:

>      blk_dread(struct blk_desc *block_dev, lbaint_t start,

>                  lbaint_t blkcnt, void *buffer)

>      blk_dwrite(struct blk_desc *block_dev, lbaint_t start,

>                  lbaint_t blkcnt, void *buffer)l

> are to be retained, at least, during the transition period

> (mostly for existing filesystems and commands).

>

>> The name 'disk' is pretty awful though, these days.

>

> Think so?

> Honestly, I'd like to rename BLK to DISK (or BLK_MEDIA) and

> rename DISK to BLK to reflect their rolls :)


Block devices are not necessarily disks. Think of a tape device for
instance or a RAM based block device. So renaming BLK to DISK is confusing.

>

>> If we want to iterate through all the partition tables across all

>> devices, we could do that with a partition uclass. We could support

>> different types of partition (s/w and h/w) with the same device

>> driver.


Why? You can simply traverse the list of udevices of type SW_PARTITION.
There is not need to walk the tree.

In the tree above you made them HW and SW partions different uclasses.
For each uclass create a separate driver.

Best regards

Heinrich

>>

>> I think conceptually it is cleaner to have a partition uclass but I do

>> agree that it corresponds 100% to BLK, so maybe there is little value

>> in practice. But which device holds the partition table in its

>> dev_get_priv()?

>

> Do you think that some device should have "partition table" info

> in its inner data structure of udevice?

> BLK-DISK relationship can represent a partition table in some way,

> and MMC-BLK can model hw partitioning.

>

> Thanks,

> -Takahiro Akashi

>

>>>

>>>>>>> Do you mean hardware partition here? Otherwise I would not know what BLK

>>>>>>> should model.

>>>>>>

>>>>>> I mean that (I think) we should not use BLK to model partitions. A BLK

>>>>>> should just be a block device.

>>>>>

>>>>> That is fine. But this implies that a software partition is the child of

>>>>> a block partition and not the other way round. So the tree should like:

>>>>>

>>>>> MMC

>>>>> |- BLK (user hardware partition)

>>>>> ||- PARTITION 1 (software partition)

>>>>> ||- PARTITION 2 (software partition)

>>>>> |...

>>>>> ||- PARTITION n (software partition)

>>>>> |- BLK (rpmb hardware partition)

>>>>> |- BLK (boot0 hardware partition)

>>>>> |- BLK (boot1 hardware partition)

>>>>

>>>> I presume you meant to include a BLK device under each PARTITION?

>>>>

>>>> But anyway, I was more thinking of this:

>>>>

>>>> MMC

>>>> | HWPARTITION rpmb

>>>> || BLK whole rpmb

>>>> || PARTITION 1

>>>> ||| BLK

>>>> || PARTITION 2

>>>> ||| BLK

>>>> || PARTITION 3

>>>

>>> Do we have any reason to model a RPMB partition as a block device?

>>> For linux, at least, mmcblkrpmb looks to be a character device.

>>>

>>>> ||| BLK

>>>> | HWPARTITION boot0

>>>> || BLK

>>>> (maybe have PARTITION in here too?

>>>

>>> I don't know how boot partitions are used on a production system.

>>> It's unlikely to have partitions on them given the purpose of "boot"

>>> partitions?

>>

>> That's true. So likely they will not be used.

>>

>>>

>>>> | HWPARTITION boot1

>>>> (maybe have PARTITION in here too?

>>>> || BLK

>>>>

>>>>>

>>>>>>

>>>>>> I don't see any difference between a partition and a hardware

>>>>>> partition. We presumably end up with a hierarchy though. Do we need a

>>>>>> HWPARTITION uclass so we can handle the hardware partitions

>>>>>> differently?

>>>>>

>>>>> Software partitions are defined and discovered via partition tables.

>>>>> Hardware partitions are defined in a hardware specific way.

>>>>>

>>>>> All software partitions map to HD() device tree nodes in UEFI.

>>>>> An MMC device maps to an eMMC() node

>>>>> MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

>>>>> do the same in U-Boot.

>>>>> An SD-card maps to an SD() node.

>>>>> An NVMe namespace maps to a NVMe() node.

>>>>> An SCSI LUN maps to a Scsi() node.

>>>>> SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

>>>>

>>>> I'm not quite sure about the terminology here. I'm not even talking

>>>> about UEFI, really, just how best to model this stuff in U-Boot.

>>>

>>> In UEFI world, each efi_disk has its own device path to identify the device.

>>> For example, here is a text representation of device path for a scsi disk

>>> partition:

>>>    /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a)

>>>

>>> which is set to be created from a corresponding udevice (more strictly

>>> blkc_desc + part).

>>>

>>> So the issue Heinrich raised here is a matter of implementation of

>>> this conversion (software partitions, and SCSI channels?) as well as

>>> a modeling for some device type on U-Boot, i.e. MMC hardware partitions.

>>

>> Yes I see that. It's just that we should get our house in order first,

>> since these discussions didn't happen when the EFI layer was written 6

>> years ago. If we have a good model for partitions (not just block

>> devices) in U-Boot then it should be easier to map EFI onto it.

>>

>> Regards,

>> Simon

>>

>>

>>>

>>> -Takahiro Akashi

>>>

>>>> In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

>>>> right? I'm a little worried it is not modelled correctly. After all,

>>>> what is the parent of a SCSI device?

>>>>

>>>>>

>>>>> The simple file protocol is only provided by HD() nodes and not by nodes

>>>>> representing hardware partitions. If the whole hardware partition is

>>>>> formatted as a file system you would still create a HD() node with

>>>>> partition number 0.

>>>>

>>>> Regards,

>>>> Simon

>>> ---

>>>>

>>>>>

>>>>> When it comes to UEFI, I hope we can currently support hw partitions

>>>>> in this way:

>>>>>    => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""

>>>>> (".1" is a key, I have never tried this syntax though.)

>>>>>

>>>>> But probably its device path won't be properly formatted

>>>>> as expected as Heinrich suggested.

>>>>>

>>>>> -Takahiro Akashi

>>>>>

>>>>>

>>>>>> In terms of modeling, this is akin to how if you use a USB card reader

>>>>>> that supports 4 different form-factor cards, you can end up with 4

>>>>>> different devices showing up in Linux (if you have one of the nice card

>>>>>> readers that supports multiple cards at once).

>>>>>>

>>>>>> --

>>>>>> Tom

>>>>>

>>>>>

>>>>

>>>> Regards,

>>>> Simon

Simon Glass Oct. 29, 2021, 1:45 a.m. UTC | #22

Hi,

On Thu, 28 Oct 2021 at 04:47, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>

>

>

> On 10/28/21 10:52, AKASHI Takahiro wrote:

> > Hi Simon,

> >

> > I'd like to resume this discussion.

> >

> > On Thu, Oct 14, 2021 at 02:55:36PM -0600, Simon Glass wrote:

> >> Hi Takahiro,

> >>

> >> On Thu, 14 Oct 2021 at 02:03, AKASHI Takahiro

> >> <takahiro.akashi@linaro.org> wrote:

> >>>

> >>> Simon,

> >>>

> >>> On Wed, Oct 13, 2021 at 12:05:58PM -0600, Simon Glass wrote:

> >>>> Hi Takahiro,

> >>>>

> >>>> On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro

> >>>> <takahiro.akashi@linaro.org> wrote:

> >>>>>

> >>>>> On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:

> >>>>>> On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:

> >>>>>>> Hi Heinrich,

> >>>>>>>

> >>>>>>> On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>> On 10/11/21 16:54, Simon Glass wrote:

> >>>>>>>>> Hi Takahiro,

> >>>>>>>>>

> >>>>>>>>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro

> >>>>>>>>> <takahiro.akashi@linaro.org> wrote:

> >>>>>>>>>>

> >>>>>>>>>> Heinrich,

> >>>>>>>>>>

> >>>>>>>>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:

> >>>>>>>>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:

> >>>>>>>>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:

> >>>>>>>>>>>>>>> UCLASS_PARTITION device will be created as a child node of

> >>>>>>>>>>>>>>> UCLASS_BLK device.

> >>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

> >>>>>>>>>>>>>>> ---

> >>>>>>>>>>>>>>>      drivers/block/blk-uclass.c | 111 +++++++++++++++++++++++++++++++++++++

> >>>>>>>>>>>>>>>      include/blk.h              |   9 +++

> >>>>>>>>>>>>>>>      include/dm/uclass-id.h     |   1 +

> >>>>>>>>>>>>>>>      3 files changed, 121 insertions(+)

> >>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c

> >>>>>>>>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644

> >>>>>>>>>>>>>>> --- a/drivers/block/blk-uclass.c

> >>>>>>>>>>>>>>> +++ b/drivers/block/blk-uclass.c

> >>>>>>>>>>>>>>> @@ -12,6 +12,7 @@

> >>>>>>>>>>>>>>>      #include <log.h>

> >>>>>>>>>>>>>>>      #include <malloc.h>

> >>>>>>>>>>>>>>>      #include <part.h>

> >>>>>>>>>>>>>>> +#include <string.h>

> >>>>>>>>>>>>>>>      #include <dm/device-internal.h>

> >>>>>>>>>>>>>>>      #include <dm/lists.h>

> >>>>>>>>>>>>>>>      #include <dm/uclass-internal.h>

> >>>>>>>>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)

> >>>>>>>>>>>>>>>         return 0;

> >>>>>>>>>>>>>>>      }

> >>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>> +int blk_create_partitions(struct udevice *parent)

> >>>>>>>>>>>>>>> +{

> >>>>>>>>>>>>>>> +     int part, count;

> >>>>>>>>>>>>>>> +     struct blk_desc *desc = dev_get_uclass_plat(parent);

> >>>>>>>>>>>>>>> +     struct disk_partition info;

> >>>>>>>>>>>>>>> +     struct disk_part *part_data;

> >>>>>>>>>>>>>>> +     char devname[32];

> >>>>>>>>>>>>>>> +     struct udevice *dev;

> >>>>>>>>>>>>>>> +     int ret;

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +     if (!CONFIG_IS_ENABLED(PARTITIONS) ||

> >>>>>>>>>>>>>>> +         !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))

> >>>>>>>>>>>>>>> +             return 0;

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +     /* Add devices for each partition */

> >>>>>>>>>>>>>>> +     for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {

> >>>>>>>>>>>>>>> +             if (part_get_info(desc, part, &info))

> >>>>>>>>>>>>>>> +                     continue;

> >>>>>>>>>>>>>>> +             snprintf(devname, sizeof(devname), "%s:%d", parent->name,

> >>>>>>>>>>>>>>> +                      part);

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +             ret = device_bind_driver(parent, "blk_partition",

> >>>>>>>>>>>>>>> +                                      strdup(devname), &dev);

> >>>>>>>>>>>>>>> +             if (ret)

> >>>>>>>>>>>>>>> +                     return ret;

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +             part_data = dev_get_uclass_plat(dev);

> >>>>>>>>>>>>>>> +             part_data->partnum = part;

> >>>>>>>>>>>>>>> +             part_data->gpt_part_info = info;

> >>>>>>>>>>>>>>> +             count++;

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +             device_probe(dev);

> >>>>>>>>>>>>>>> +     }

> >>>>>>>>>>>>>>> +     debug("%s: %d partitions found in %s\n", __func__, count, parent->name);

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +     return 0;

> >>>>>>>>>>>>>>> +}

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>>      static int blk_post_probe(struct udevice *dev)

> >>>>>>>>>>>>>>>      {

> >>>>>>>>>>>>>>>         if (IS_ENABLED(CONFIG_PARTITIONS) &&

> >>>>>>>>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {

> >>>>>>>>>>>>>>>         .post_probe     = blk_post_probe,

> >>>>>>>>>>>>>>>         .per_device_plat_auto   = sizeof(struct blk_desc),

> >>>>>>>>>>>>>>>      };

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,

> >>>>>>>>>>>>>>> +                        lbaint_t blkcnt, void *buffer)

> >>>>>>>>>>>>>>> +{

> >>>>>>>>>>>>>>> +     struct udevice *parent;

> >>>>>>>>>>>>>>> +     struct disk_part *part;

> >>>>>>>>>>>>>>> +     const struct blk_ops *ops;

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +     parent = dev_get_parent(dev);

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>>> What device type will the parent have if it is a eMMC hardware partition?

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>>>> +     ops = blk_get_ops(parent);

> >>>>>>>>>>>>>>> +     if (!ops->read)

> >>>>>>>>>>>>>>> +             return -ENOSYS;

> >>>>>>>>>>>>>>> +

> >>>>>>>>>>>>>>> +     part = dev_get_uclass_plat(dev);

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>>> You should check that we do not access the block device past the

> >>>>>>>>>>>>>> partition end:

> >>>>>>>>>>>>>

> >>>>>>>>>>>>> Yes, I will fix all of checks.

> >>>>>>>>>>>>>

> >>>>>>>>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);

> >>>>>>>>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)

> >>>>>>>>>>>>>>           return -EFAULT.

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>>>> +     start += part->gpt_part_info.start;

> >>>>>>>>>>>>

> >>>>>>>>>>>> A better solution is:

> >>>>>>>>>>>>            if (start >= part->gpt_part_info.size)

> >>>>>>>>>>>>                    return 0;

> >>>>>>>>>>>>

> >>>>>>>>>>>>            if ((start + blkcnt) > part->gpt_part_info.size)

> >>>>>>>>>>>>                    blkcnt = part->gpt_part_info.size - start;

> >>>>>>>>>>>>            start += part->gpt_part_info.start;

> >>>>>>>>>>>> instead of returning -EFAULT.

> >>>>>>>>>>>> (note that start and blkcnt are in "block".)

> >>>>>>>>>>>

> >>>>>>>>>>> What is your motivation to support an illegal access?

> >>>>>>>>>>>

> >>>>>>>>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this function. The

> >>>>>>>>>>> ReadBlocks() and WriteBlocks() services must return

> >>>>>>>>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are not

> >>>>>>>>>>> valid.

> >>>>>>>>>>

> >>>>>>>>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,

> >>>>>>>>>> and that if the starting block is out of partition region, we should

> >>>>>>>>>> return an error (and if not, we still want to trim IO request to fit

> >>>>>>>>>> into partition size as other OS's API like linux does).

> >>>>>>>>>> Do you think it's incorrect?

> >>>>>>>>>

> >>>>>>>>> [..]

> >>>>>>>>>

> >>>>>>>>> Related to this patch I think that the partition type should be really

> >>>>>>>>> be a child of the media device:

> >>>>>>>>>

> >>>>>>>>> - MMC

> >>>>>>>>>       |- BLK

> >>>>>>>>>       |- PARTITION

> >>>>>>>>>          |- BLK

> >>>>>>>>>       |- PARTITION

> >>>>>>>>>          |- BLK

> >>>>>>>>>       |- PARTITION

> >>>>>>>>>          |- BLK

> >>>>>>>>>

> >>>>>>>>> It seems more natural to me that putting the partitions under the

> >>>>>>>>> top-level BLK device, so that BLK remains a 'terminal' device.

> >>>>>>>>>

> >>>>>>>>> The partition uclass is different from BLK, of course. It could

> >>>>>>>>> contain information about the partition such as its partition number

> >>>>>>>>> and UUID.

> >>>>>>>>

> >>>>>>>> Do you mean hardware partition here? Otherwise I would not know what BLK

> >>>>>>>> should model.

> >>>>>>>

> >>>>>>> I mean that (I think) we should not use BLK to model partitions. A BLK

> >>>>>>> should just be a block device.

> >>>>>>>

> >>>>>>> I don't see any difference between a partition and a hardware

> >>>>>>> partition. We presumably end up with a hierarchy though. Do we need a

> >>>>>>> HWPARTITION uclass so we can handle the hardware partitions

> >>>>>>> differently?

> >>>>>>

> >>>>>> Note that for eMMC devices, hardware partitions are different from

> >>>>>> partition-table partitions.  If you boot a system with an eMMC device up

> >>>>>> in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and

> >>>>>> mmcblkNrpmb, each of which are hardware partitions.  It gets tricky in

> >>>>>> U-Boot in that you can access each of these with 'mmc dev N M' where M

> >>>>>> defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1

> >>>>>> and 3 is the rpmb area.  The 'mmc' command also allows, when possible

> >>>>>> and implemented, configuring these partitions, again to the extent

> >>>>>> allowed, documented and implemented.

> >>>>>

> >>>>> Thank you. That is exactly what I tried to mention in my reply

> >>>>> at "part: call part_init() in blk_get_device_by_str() only for MMC"

> >>>>

> >>>> OK so it sounds like we agree that hwpartition and partition are

> >>>> different things.

> >>>

> >>> Yes.

> >>> Please note, IIUC, that

> >>> * MMC hw partitions on a device are mapped to one udevice, differentiating

> >>>    them by blk_desc->hwpart.

> >>> * Each NVME namespace on a device is mapped to a different udevice with

> >>>    a different blk_desc->devnum (and nvme_dev->ns_id).

> >>> * Each UFS partition (or which is, I suppose, equivalent to scsi LUN) on

> >>>    a device is mapped to a different udevice with a different blk_desc->devnum

> >>>    (and blk_desc->lun).

> >>>

> >>> So even though those type of devices have some kind of hardware partitions,

> >>> they are modelled differently in U-Boot.

> >>> (Obviously, I might be wrong here as I'm not quite familiar yet.)

> >>>

> >>>>>

> >>>>> ---8<---

> >>>>> # On the other hand, we have to explicitly switch "hw partitions"

> >>>>> # with blk_select_hwpart_devnum() on MMC devices even though we use

> >>>>> # the *same* udevice(blk_desc).

> >>>>> --->8---

> >>>>>

> >>>>> The problem with the current U-Boot driver model is that all of "mmcblkN,

> >>>>> mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same

> >>>>> udevice. We have to do "mmc dev N M" or call blk_select_hwpart[_devnum]()

> >>>>> to distinguish them.

> >>>>

> >>>> Here's our chance to rethink this. What should the device hierarchy be

> >>>> for an MMC device? I made a proposal further up the thread.

> >>>

> >>> Well,

> >>>

> >>> On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:

> >>>> On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >>>

> >>>>>>>> [..]

> >>>

> >>>>>>>> Related to this patch I think that the partition type should be really

> >>>>>>>> be a child of the media device:

> >>>>>>>>

> >>>>>>>> - MMC

> >>>>>>>>        |- BLK

> >>>>>>>>        |- PARTITION

> >>>>>>>>           |- BLK

> >>>>>>>>        |- PARTITION

> >>>>>>>>           |- BLK

> >>>>>>>>        |- PARTITION

> >>>>>>>>           |- BLK

> >>>>>>>>

> >>>>>>>> It seems more natural to me that putting the partitions under the

> >>>>>>>> top-level BLK device, so that BLK remains a 'terminal' device.

> >>>>>>>>

> >>>>>>>> The partition uclass is different from BLK, of course. It could

> >>>>>>>> contain information about the partition such as its partition number

> >>>>>>>> and UUID.

> >>>

> >>> Yeah, but there is always 1-to-1 mapping between a partition and

> >>> a block (for a partition), so I still wonder whether it makes sense

> >>> to model partitions in the way above.

> >>>

> >>> Alternatively, the following hierarchy also makes some sense.

> >>> (This is not what I have in my RFC though.)

> >>> - MMC

> >>> |- BLK (whole disk with part=0)

> >>> |- BLK (partition 1)

> >>> |- BLK (partition 2)

> >>> |- BLK (partition 3)

> >>>

> >>> or

> >>>

> >>> - MMC

> >>> |- DISK (whole disk)

> >>> ||- BLK (partition 0)

> >>> ||- BLK (partition 1)

> >>> ||- BLK (partition 2)

> >>> ||- BLK (partition 3)

> >>>

> >>> Here

> >>> MMC: provides read/write operations (via blk_ops)

> >>> DISK: holds a geometry of a whole disk and other info

> >>> BLK: partition info (+ blk_ops + geo) (part=0 means a while disk)

> >>

> >> Where does this leave hwpart? Are we giving up on that?

> >

> > No, not at all :)

> > I'm thinking of dealing with hw partitions as independent BLK devices.

> > This is already true for NVME (namespaces) and UFS (LUNs)(not sure, though).

> > For MMC, struct blk_desc has 'hwpart' field to indicate a hw partition and

> > Apparently, it will be easy to have different BLK devices with

> > different hwpart's.

> > (Then we will have to add a probe function for hw partitions.)

> >

> >> Both of these make some sense to me, although I'm not sure what the

> >> second one buys us. Can you explain that? Is it to deal with hwpart?

> >

> > So,

> >

> > - MMC (bus controller)

> > |- BLK (device/hw partition:user data)

> > ||- DISK (partition 0 == a whole device)

> > ||- DISK (partition 1)

> > ||- DISK (partition 2)

> > ||- DISK (partition 3)

> > |- BLK (device/hw partition:boot0)

> > ||- DISK (partition 0 == a whole device)

> > |- BLK (device/hw partition:boot0)

> > ||- DISK (partition 0 == a whole device)

> > |- BLK (device/hw partition:rpmb) -- this is NOT a 'block' device, though.

> > ||- DISK (partition 0 == a whole device)

> >

> >      MMC: provides access methods (via blk_ops)

> >      BLK: represents a physical device and holds a geometry of the whole

> >           device and other info

> >      DISK: block-access entities with partition info

> >            (part=0 means a while disk)

> >

> >      (MMC, BLK are of current implementation.)


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?

- Simon

>

> Could you, please, add the path from the root, devices without hardware

> partitions (e.g. IDE, SATA), and devices with LUNs (SCSI) to the tree.

> Please, also add the device-tree nodes. This will allow us to see the

> whole picture, and observe how UEFI device paths and the DM tree are

> matched.

>

> >

> > To avoid confusion, UCLASS_PARTITION is renamed to UCLASS_DISK with

> > a little modified semantics. The name can be seen aligned with 'disk/'

>

> Renaming UCLASS_PARTITION to UCLASS_DISK is very confusing. A disk to me

> is a block device which may have partitions.

>

> > directory for sw partitions.

> > Partition 0 expectedly behaves in the same way as an existing BLK.

>

> It will expose block IO and it may expose a file system.

> The same is valid for the true partitions.

>

> A block device does not expose a file system.

>

> So partition 0 just behaves at it always did in U-Boot.

>

>

> >

> > With this scheme, I assume that we should thoroughly use new interfaces

> >      dev_read(struct udevice *dev, lbaint_t start,

> >                  lbaint_t blkcnt, void *buffer);

> >      dev_write(struct udevice *dev, lbaint_t start,

> >                  lbaint_t blkcnt, void *buffer);

> > for block-level operations with DISK devices.

> >                                  ^^^^

> >

> > The legacy interfaces with blk_desc's in BLK devices:

> >      blk_dread(struct blk_desc *block_dev, lbaint_t start,

> >                  lbaint_t blkcnt, void *buffer)

> >      blk_dwrite(struct blk_desc *block_dev, lbaint_t start,

> >                  lbaint_t blkcnt, void *buffer)l

> > are to be retained, at least, during the transition period

> > (mostly for existing filesystems and commands).

> >

> >> The name 'disk' is pretty awful though, these days.

> >

> > Think so?

> > Honestly, I'd like to rename BLK to DISK (or BLK_MEDIA) and

> > rename DISK to BLK to reflect their rolls :)

>

> Block devices are not necessarily disks. Think of a tape device for

> instance or a RAM based block device. So renaming BLK to DISK is confusing.

>

> >

> >> If we want to iterate through all the partition tables across all

> >> devices, we could do that with a partition uclass. We could support

> >> different types of partition (s/w and h/w) with the same device

> >> driver.

>

> Why? You can simply traverse the list of udevices of type SW_PARTITION.

> There is not need to walk the tree.

>

> In the tree above you made them HW and SW partions different uclasses.

> For each uclass create a separate driver.

>

> Best regards

>

> Heinrich

>

> >>

> >> I think conceptually it is cleaner to have a partition uclass but I do

> >> agree that it corresponds 100% to BLK, so maybe there is little value

> >> in practice. But which device holds the partition table in its

> >> dev_get_priv()?

> >

> > Do you think that some device should have "partition table" info

> > in its inner data structure of udevice?

> > BLK-DISK relationship can represent a partition table in some way,

> > and MMC-BLK can model hw partitioning.

> >

> > Thanks,

> > -Takahiro Akashi

> >

> >>>

> >>>>>>> Do you mean hardware partition here? Otherwise I would not know what BLK

> >>>>>>> should model.

> >>>>>>

> >>>>>> I mean that (I think) we should not use BLK to model partitions. A BLK

> >>>>>> should just be a block device.

> >>>>>

> >>>>> That is fine. But this implies that a software partition is the child of

> >>>>> a block partition and not the other way round. So the tree should like:

> >>>>>

> >>>>> MMC

> >>>>> |- BLK (user hardware partition)

> >>>>> ||- PARTITION 1 (software partition)

> >>>>> ||- PARTITION 2 (software partition)

> >>>>> |...

> >>>>> ||- PARTITION n (software partition)

> >>>>> |- BLK (rpmb hardware partition)

> >>>>> |- BLK (boot0 hardware partition)

> >>>>> |- BLK (boot1 hardware partition)

> >>>>

> >>>> I presume you meant to include a BLK device under each PARTITION?

> >>>>

> >>>> But anyway, I was more thinking of this:

> >>>>

> >>>> MMC

> >>>> | HWPARTITION rpmb

> >>>> || BLK whole rpmb

> >>>> || PARTITION 1

> >>>> ||| BLK

> >>>> || PARTITION 2

> >>>> ||| BLK

> >>>> || PARTITION 3

> >>>

> >>> Do we have any reason to model a RPMB partition as a block device?

> >>> For linux, at least, mmcblkrpmb looks to be a character device.

> >>>

> >>>> ||| BLK

> >>>> | HWPARTITION boot0

> >>>> || BLK

> >>>> (maybe have PARTITION in here too?

> >>>

> >>> I don't know how boot partitions are used on a production system.

> >>> It's unlikely to have partitions on them given the purpose of "boot"

> >>> partitions?

> >>

> >> That's true. So likely they will not be used.

> >>

> >>>

> >>>> | HWPARTITION boot1

> >>>> (maybe have PARTITION in here too?

> >>>> || BLK

> >>>>

> >>>>>

> >>>>>>

> >>>>>> I don't see any difference between a partition and a hardware

> >>>>>> partition. We presumably end up with a hierarchy though. Do we need a

> >>>>>> HWPARTITION uclass so we can handle the hardware partitions

> >>>>>> differently?

> >>>>>

> >>>>> Software partitions are defined and discovered via partition tables.

> >>>>> Hardware partitions are defined in a hardware specific way.

> >>>>>

> >>>>> All software partitions map to HD() device tree nodes in UEFI.

> >>>>> An MMC device maps to an eMMC() node

> >>>>> MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should

> >>>>> do the same in U-Boot.

> >>>>> An SD-card maps to an SD() node.

> >>>>> An NVMe namespace maps to a NVMe() node.

> >>>>> An SCSI LUN maps to a Scsi() node.

> >>>>> SCSI channels of multiple channel controllers are mapped to Ctrl() nodes.

> >>>>

> >>>> I'm not quite sure about the terminology here. I'm not even talking

> >>>> about UEFI, really, just how best to model this stuff in U-Boot.

> >>>

> >>> In UEFI world, each efi_disk has its own device path to identify the device.

> >>> For example, here is a text representation of device path for a scsi disk

> >>> partition:

> >>>    /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a)

> >>>

> >>> which is set to be created from a corresponding udevice (more strictly

> >>> blkc_desc + part).

> >>>

> >>> So the issue Heinrich raised here is a matter of implementation of

> >>> this conversion (software partitions, and SCSI channels?) as well as

> >>> a modeling for some device type on U-Boot, i.e. MMC hardware partitions.

> >>

> >> Yes I see that. It's just that we should get our house in order first,

> >> since these discussions didn't happen when the EFI layer was written 6

> >> years ago. If we have a good model for partitions (not just block

> >> devices) in U-Boot then it should be easier to map EFI onto it.

> >>

> >> Regards,

> >> Simon

> >>

> >>

> >>>

> >>> -Takahiro Akashi

> >>>

> >>>> In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,

> >>>> right? I'm a little worried it is not modelled correctly. After all,

> >>>> what is the parent of a SCSI device?

> >>>>

> >>>>>

> >>>>> The simple file protocol is only provided by HD() nodes and not by nodes

> >>>>> representing hardware partitions. If the whole hardware partition is

> >>>>> formatted as a file system you would still create a HD() node with

> >>>>> partition number 0.

> >>>>

> >>>> Regards,

> >>>> Simon

> >>> ---

> >>>>

> >>>>>

> >>>>> When it comes to UEFI, I hope we can currently support hw partitions

> >>>>> in this way:

> >>>>>    => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""

> >>>>> (".1" is a key, I have never tried this syntax though.)

> >>>>>

> >>>>> But probably its device path won't be properly formatted

> >>>>> as expected as Heinrich suggested.

> >>>>>

> >>>>> -Takahiro Akashi

> >>>>>

> >>>>>

> >>>>>> In terms of modeling, this is akin to how if you use a USB card reader

> >>>>>> that supports 4 different form-factor cards, you can end up with 4

> >>>>>> different devices showing up in Linux (if you have one of the nice card

> >>>>>> readers that supports multiple cards at once).

> >>>>>>

> >>>>>> --

> >>>>>> Tom

> >>>>>

> >>>>>

> >>>>

> >>>> Regards,

> >>>> Simon

Heinrich Schuchardt Oct. 29, 2021, 4:57 a.m. UTC | #23

> 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.

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.

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)
| | |-- Partition table (UCLASS_PARTITION_TABLE)
| |   |-- Software Partition (UCLASS_BLK)
| |     |-- File system (UCLASS_FS)
| |
| |-- Block device (UCLASS_BLK)
|   |-- File system (UCLASS_FS)

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

AKASHI Takahiro Oct. 29, 2021, 6:15 a.m. UTC | #24

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.
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?

|-- 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.

-Takahiro Akashi

> 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

Heinrich Schuchardt Oct. 29, 2021, 7:21 p.m. UTC | #25

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.

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.

Best regards
Heinrich 

>

>-Takahiro Akashi

>

>> 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

Simon Glass Oct. 29, 2021, 9:17 p.m. UTC | #26

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.

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

Heinrich Schuchardt Oct. 30, 2021, 5:45 a.m. UTC | #27

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?

Regards

Heinrich 


>

>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

AKASHI Takahiro Nov. 1, 2021, 12:36 a.m. UTC | #28

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?

-Takahiro Akashi

> Regards

> 

> Heinrich 

> 

> 

> >

> >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

Simon Glass Nov. 1, 2021, 1:15 a.m. UTC | #29

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.

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

AKASHI Takahiro Nov. 1, 2021, 1:51 a.m. UTC | #30

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

Simon Glass Nov. 1, 2021, 2:14 a.m. UTC | #31

Hi Takahiro,

On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
<takahiro.akashi@linaro.org> 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

> > <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.


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 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

AKASHI Takahiro Nov. 2, 2021, 1:42 a.m. UTC | #32

On Sun, Oct 31, 2021 at 08:14:13PM -0600, Simon Glass wrote:
> Hi Takahiro,

> 

> On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro

> <takahiro.akashi@linaro.org> 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

> > > <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.

> 

> 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.


I don't still understand why we need a "partition table" device in DM tree.

As I proposed in my message on Oct 28th, the hierarchy like

- MMC (bus controller)
|- BLK (device/hw partition:user data)
||- DISK (partition 0 == a whole device)
||- DISK (partition 1)
||- DISK (partition 2)
||- DISK (partition 3)
|- BLK (device/hw partition:boot0)
||- DISK (partition 0 == a whole device)
|- BLK (device/hw partition:boot0)
||- DISK (partition 0 == a whole device)
|- BLK (device/hw partition:rpmb) -- this is NOT a 'block' device, though.
||- DISK (partition 0 == a whole device)

is good enough to represent the partition relationships, ie.
   BLK-DISK for s/w partition
   MMC-BLK for h/w partition
 
If you don't like the name DISK (or UCLASS_PARTITION in my RFC),
it can be BLK_PARTITION ore even be transformed to BLK with (new)
IF_TYPE_PARTITION.
(I'd rather prefer to rename BLK->BLK_MEDIA and DISK->BLK, but
 don't stick to this idea.)

Please remember UCLASS_PARTITION devices hold partition information
(offset and size) and we don't need to scan the disk every time to access.

Currently, UCLASS_MMC doesn't support h/w partitions as standalone BLK
devices, but we can manage to modify the drivers.
(In this sense, it is much preferable to have a "h/w partition table"
device in DM tree, rather than "s/w table", as the former represents
a real "hardware" device.

-Takahiro Akashi


> 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 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

Heinrich Schuchardt Nov. 2, 2021, 7:38 a.m. UTC | #33

On 11/1/21 03:14, Simon Glass wrote:
> Hi Takahiro,

>

> On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro

> <takahiro.akashi@linaro.org> 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

>>> <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.

>

> 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 add

- 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 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

Simon Glass Nov. 5, 2021, 2:02 a.m. UTC | #34

Hi,

On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>

>

>

> On 11/1/21 03:14, Simon Glass wrote:

> > Hi Takahiro,

> >

> > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro

> > <takahiro.akashi@linaro.org> 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

> >>> <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.

> >

> > 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 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

AKASHI Takahiro Nov. 5, 2021, 2:49 a.m. UTC | #35

On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> Hi,

> 

> On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> >

> >

> >

> > On 11/1/21 03:14, Simon Glass wrote:

> > > Hi Takahiro,

> > >

> > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro

> > > <takahiro.akashi@linaro.org> 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

> > >>> <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.

> > >

> > > 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().


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.

-Takahiro Akashi


> >

> > 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 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

Simon Glass Nov. 5, 2021, 4:12 p.m. UTC | #36

Hi Takahiro,

On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>

> On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:

> > Hi,

> >

> > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> > >

> > >

> > >

> > > On 11/1/21 03:14, Simon Glass wrote:

> > > > Hi Takahiro,

> > > >

> > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro

> > > > <takahiro.akashi@linaro.org> 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

> > > >>> <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.

> > > >

> > > > 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().

>

> 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 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 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

AKASHI Takahiro Nov. 8, 2021, 4:46 a.m. UTC | #37

On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> Hi Takahiro,
> 
> On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> >
> > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > >
> > > >
> > > >
> > > > On 11/1/21 03:14, Simon Glass wrote:
> > > > > Hi Takahiro,
> > > > >
> > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > > > <takahiro.akashi@linaro.org> 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
> > > > >>> <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.
> > > > >
> > > > > 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().
> >
> > 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?

- First of all, a partition table doesn't look like a 'device' at all.
- Second, a partition table is just static data for block devices.
  IMO, even if we want to have this data, we can simply hold it
  as some sort of attribute of the device, or maybe as a 'tag' which
  I will introduce in the next version.

-Takahiro Akashi



> Regards,
> Simon
> 
> 
> >
> > -Takahiro Akashi
> >
> >
> > > >
> > > > 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 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

Ilias Apalodimas Nov. 8, 2021, 6:44 p.m. UTC | #38

Hi chiming in a little late but

On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>
> On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > >
> > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 11/1/21 03:14, Simon Glass wrote:
> > > > > > Hi Takahiro,
> > > > > >
> > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > > > > <takahiro.akashi@linaro.org> 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
> > > > > >>> <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.
> > > > > >
> > > > > > 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().
> > >
> > > 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?
>
> - First of all, a partition table doesn't look like a 'device' at all.
> - Second, a partition table is just static data for block devices.
>   IMO, even if we want to have this data, we can simply hold it
>   as some sort of attribute of the device, or maybe as a 'tag' which
>   I will introduce in the next version.
>
> -Takahiro Akashi
>

I don't know how this affect the code, but I agree with Akashi-san
here.  It's indeed useful to keep the partition table stored
somewhere,  but I think not showing them as part of the device tree is
more intuitive.

Thanks
/Ilias
[...]

Simon Glass Nov. 9, 2021, 12:09 a.m. UTC | #39

Hi,

On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi chiming in a little late but
>
> On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> >
> > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > >
> > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/1/21 03:14, Simon Glass wrote:
> > > > > > > Hi Takahiro,
> > > > > > >
> > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > > > > > <takahiro.akashi@linaro.org> 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
> > > > > > >>> <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.
> > > > > > >
> > > > > > > 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().
> > > >
> > > > 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?
> >
> > - First of all, a partition table doesn't look like a 'device' at all.
> > - Second, a partition table is just static data for block devices.
> >   IMO, even if we want to have this data, we can simply hold it
> >   as some sort of attribute of the device, or maybe as a 'tag' which
> >   I will introduce in the next version.
> >
> > -Takahiro Akashi
> >
>
> I don't know how this affect the code, but I agree with Akashi-san
> here.  It's indeed useful to keep the partition table stored
> somewhere,  but I think not showing them as part of the device tree is
> more intuitive.

Well I think I'm easy either way. I just thought that Heinrich made a
good case for having a partition uclass.

But as Takahiro says, we can use a tag to attach the partition table
to the device. But it should be attached to the device's children (the
BLK device) not the media device itself, right?

Regards,
Simon

Simon Glass Nov. 13, 2021, 6:14 p.m. UTC | #40

Hi,

On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
>
> Hi,
>
> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi chiming in a little late but
> >
> > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > >
> > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > > > Hi Takahiro,
> > > >
> > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > > >
> > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/1/21 03:14, Simon Glass wrote:
> > > > > > > > Hi Takahiro,
> > > > > > > >
> > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > > > > > > <takahiro.akashi@linaro.org> 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
> > > > > > > >>> <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.
> > > > > > > >
> > > > > > > > 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().
> > > > >
> > > > > 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?
> > >
> > > - First of all, a partition table doesn't look like a 'device' at all.
> > > - Second, a partition table is just static data for block devices.
> > >   IMO, even if we want to have this data, we can simply hold it
> > >   as some sort of attribute of the device, or maybe as a 'tag' which
> > >   I will introduce in the next version.
> > >
> > > -Takahiro Akashi
> > >
> >
> > I don't know how this affect the code, but I agree with Akashi-san
> > here.  It's indeed useful to keep the partition table stored
> > somewhere,  but I think not showing them as part of the device tree is
> > more intuitive.
>
> Well I think I'm easy either way. I just thought that Heinrich made a
> good case for having a partition uclass.
>
> But as Takahiro says, we can use a tag to attach the partition table
> to the device. But it should be attached to the device's children (the
> BLK device) not the media device itself, right?

As there has been no discussion in 5 days and Takahiro is writing
this, let's go with no uclass for the partition table.

Regards,
Simon

Heinrich Schuchardt Nov. 13, 2021, 6:37 p.m. UTC | #41

Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg@chromium.org>:
>Hi,
>
>On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi,
>>
>> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
>> <ilias.apalodimas@linaro.org> wrote:
>> >
>> > Hi chiming in a little late but
>> >
>> > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>> > >
>> > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
>> > > > Hi Takahiro,
>> > > >
>> > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>> > > > >
>> > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On 11/1/21 03:14, Simon Glass wrote:
>> > > > > > > > Hi Takahiro,
>> > > > > > > >
>> > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
>> > > > > > > > <takahiro.akashi@linaro.org> 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
>> > > > > > > >>> <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.
>> > > > > > > >
>> > > > > > > > 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().
>> > > > >
>> > > > > 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?
>> > >
>> > > - First of all, a partition table doesn't look like a 'device' at all.
>> > > - Second, a partition table is just static data for block devices.
>> > >   IMO, even if we want to have this data, we can simply hold it
>> > >   as some sort of attribute of the device, or maybe as a 'tag' which
>> > >   I will introduce in the next version.
>> > >
>> > > -Takahiro Akashi
>> > >
>> >
>> > I don't know how this affect the code, but I agree with Akashi-san
>> > here.  It's indeed useful to keep the partition table stored
>> > somewhere,  but I think not showing them as part of the device tree is
>> > more intuitive.
>>
>> Well I think I'm easy either way. I just thought that Heinrich made a
>> good case for having a partition uclass.
>>
>> But as Takahiro says, we can use a tag to attach the partition table
>> to the device. But it should be attached to the device's children (the
>> BLK device) not the media device itself, right?
>
>As there has been no discussion in 5 days and Takahiro is writing
>this, let's go with no uclass for the partition table.
>

Without uclass you cannot bring the partition table drivers into th driver model.

No clue what a tag should be in the driver model.

Best regards

Heinrich

>Regards,
>Simon

Simon Glass Nov. 13, 2021, 9:32 p.m. UTC | #42

Hi Heinrich,

On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg@chromium.org>:
> >Hi,
> >
> >On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
> >> <ilias.apalodimas@linaro.org> wrote:
> >> >
> >> > Hi chiming in a little late but
> >> >
> >> > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> >> > >
> >> > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> >> > > > Hi Takahiro,
> >> > > >
> >> > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> >> > > > >
> >> > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On 11/1/21 03:14, Simon Glass wrote:
> >> > > > > > > > Hi Takahiro,
> >> > > > > > > >
> >> > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> >> > > > > > > > <takahiro.akashi@linaro.org> 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
> >> > > > > > > >>> <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.
> >> > > > > > > >
> >> > > > > > > > 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().
> >> > > > >
> >> > > > > 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?
> >> > >
> >> > > - First of all, a partition table doesn't look like a 'device' at all.
> >> > > - Second, a partition table is just static data for block devices.
> >> > >   IMO, even if we want to have this data, we can simply hold it
> >> > >   as some sort of attribute of the device, or maybe as a 'tag' which
> >> > >   I will introduce in the next version.
> >> > >
> >> > > -Takahiro Akashi
> >> > >
> >> >
> >> > I don't know how this affect the code, but I agree with Akashi-san
> >> > here.  It's indeed useful to keep the partition table stored
> >> > somewhere,  but I think not showing them as part of the device tree is
> >> > more intuitive.
> >>
> >> Well I think I'm easy either way. I just thought that Heinrich made a
> >> good case for having a partition uclass.
> >>
> >> But as Takahiro says, we can use a tag to attach the partition table
> >> to the device. But it should be attached to the device's children (the
> >> BLK device) not the media device itself, right?
> >
> >As there has been no discussion in 5 days and Takahiro is writing
> >this, let's go with no uclass for the partition table.
> >
>
> Without uclass you cannot bring the partition table drivers into th driver model.
>
> No clue what a tag should be in the driver model.

A tag is a way to associate data with a device. At present we do this
with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.)
but with tags you can add something else.

Regards,
Simon

AKASHI Takahiro Nov. 15, 2021, 1:43 a.m. UTC | #43

Hi Simon,

On Sat, Nov 13, 2021 at 02:32:20PM -0700, Simon Glass wrote:
> Hi Heinrich,
> 
> On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >
> > Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg@chromium.org>:
> > >Hi,
> > >
> > >On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
> > >> <ilias.apalodimas@linaro.org> wrote:
> > >> >
> > >> > Hi chiming in a little late but
> > >> >
> > >> > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > >> > >
> > >> > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > >> > > > Hi Takahiro,
> > >> > > >
> > >> > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > >> > > > >
> > >> > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > >> > > > > > Hi,
> > >> > > > > >
> > >> > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > On 11/1/21 03:14, Simon Glass wrote:
> > >> > > > > > > > Hi Takahiro,
> > >> > > > > > > >
> > >> > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > >> > > > > > > > <takahiro.akashi@linaro.org> 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
> > >> > > > > > > >>> <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.
> > >> > > > > > > >
> > >> > > > > > > > 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().
> > >> > > > >
> > >> > > > > 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?
> > >> > >
> > >> > > - First of all, a partition table doesn't look like a 'device' at all.
> > >> > > - Second, a partition table is just static data for block devices.
> > >> > >   IMO, even if we want to have this data, we can simply hold it
> > >> > >   as some sort of attribute of the device, or maybe as a 'tag' which
> > >> > >   I will introduce in the next version.
> > >> > >
> > >> > > -Takahiro Akashi
> > >> > >
> > >> >
> > >> > I don't know how this affect the code, but I agree with Akashi-san
> > >> > here.  It's indeed useful to keep the partition table stored
> > >> > somewhere,  but I think not showing them as part of the device tree is
> > >> > more intuitive.
> > >>
> > >> Well I think I'm easy either way. I just thought that Heinrich made a
> > >> good case for having a partition uclass.
> > >>
> > >> But as Takahiro says, we can use a tag to attach the partition table
> > >> to the device. But it should be attached to the device's children (the
> > >> BLK device) not the media device itself, right?
> > >
> > >As there has been no discussion in 5 days and Takahiro is writing
> > >this, let's go with no uclass for the partition table.
> > >
> >
> > Without uclass you cannot bring the partition table drivers into th driver model.

This transition may be able to be done later when really necessary
as long as we agree that a partition table be hold within a "raw" disk
object (with a tag support).
# I don't think we need it for now.

> > No clue what a tag should be in the driver model.
> 
> A tag is a way to associate data with a device. At present we do this
> with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.)
> but with tags you can add something else.

Since this discussion thread is getting too long, I would like
to respin my RFC. How should I deal with your "event notification"
proposal?

-Takahiro Akashi


> Regards,
> Simon

Simon Glass Nov. 15, 2021, 7:05 p.m. UTC | #44

Hi Takahiro,

On Sun, 14 Nov 2021 at 18:43, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> Hi Simon,
>
> On Sat, Nov 13, 2021 at 02:32:20PM -0700, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > >
> > > Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg@chromium.org>:
> > > >Hi,
> > > >
> > > >On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
> > > >> <ilias.apalodimas@linaro.org> wrote:
> > > >> >
> > > >> > Hi chiming in a little late but
> > > >> >
> > > >> > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > >> > >
> > > >> > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > > >> > > > Hi Takahiro,
> > > >> > > >
> > > >> > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > >> > > > >
> > > >> > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > >> > > > > > Hi,
> > > >> > > > > >
> > > >> > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > On 11/1/21 03:14, Simon Glass wrote:
> > > >> > > > > > > > Hi Takahiro,
> > > >> > > > > > > >
> > > >> > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > >> > > > > > > > <takahiro.akashi@linaro.org> 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
> > > >> > > > > > > >>> <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.
> > > >> > > > > > > >
> > > >> > > > > > > > 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().
> > > >> > > > >
> > > >> > > > > 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?
> > > >> > >
> > > >> > > - First of all, a partition table doesn't look like a 'device' at all.
> > > >> > > - Second, a partition table is just static data for block devices.
> > > >> > >   IMO, even if we want to have this data, we can simply hold it
> > > >> > >   as some sort of attribute of the device, or maybe as a 'tag' which
> > > >> > >   I will introduce in the next version.
> > > >> > >
> > > >> > > -Takahiro Akashi
> > > >> > >
> > > >> >
> > > >> > I don't know how this affect the code, but I agree with Akashi-san
> > > >> > here.  It's indeed useful to keep the partition table stored
> > > >> > somewhere,  but I think not showing them as part of the device tree is
> > > >> > more intuitive.
> > > >>
> > > >> Well I think I'm easy either way. I just thought that Heinrich made a
> > > >> good case for having a partition uclass.
> > > >>
> > > >> But as Takahiro says, we can use a tag to attach the partition table
> > > >> to the device. But it should be attached to the device's children (the
> > > >> BLK device) not the media device itself, right?
> > > >
> > > >As there has been no discussion in 5 days and Takahiro is writing
> > > >this, let's go with no uclass for the partition table.
> > > >
> > >
> > > Without uclass you cannot bring the partition table drivers into th driver model.
>
> This transition may be able to be done later when really necessary
> as long as we agree that a partition table be hold within a "raw" disk
> object (with a tag support).
> # I don't think we need it for now.
>
> > > No clue what a tag should be in the driver model.
> >
> > A tag is a way to associate data with a device. At present we do this
> > with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.)
> > but with tags you can add something else.
>
> Since this discussion thread is getting too long, I would like
> to respin my RFC. How should I deal with your "event notification"
> proposal?

Is the patch good enough to include in the series?

If not, you could reply to it with what needs doing.

Regards,
Simon

Heinrich Schuchardt Nov. 15, 2021, 7:16 p.m. UTC | #45

On 11/15/21 20:05, Simon Glass wrote:
> Hi Takahiro,
>
> On Sun, 14 Nov 2021 at 18:43, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
>>
>> Hi Simon,
>>
>> On Sat, Nov 13, 2021 at 02:32:20PM -0700, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>
>>>> Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg@chromium.org>:
>>>>> Hi,
>>>>>
>>>>> On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
>>>>>> <ilias.apalodimas@linaro.org> wrote:
>>>>>>>
>>>>>>> Hi chiming in a little late but
>>>>>>>
>>>>>>> On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>>>>>>>>
>>>>>>>> On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
>>>>>>>>> Hi Takahiro,
>>>>>>>>>
>>>>>>>>> On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/1/21 03:14, Simon Glass wrote:
>>>>>>>>>>>>> Hi Takahiro,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
>>>>>>>>>>>>> <takahiro.akashi@linaro.org> 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
>>>>>>>>>>>>>>> <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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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().
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>
>>>>>>>> - First of all, a partition table doesn't look like a 'device' at all.
>>>>>>>> - Second, a partition table is just static data for block devices.
>>>>>>>>    IMO, even if we want to have this data, we can simply hold it
>>>>>>>>    as some sort of attribute of the device, or maybe as a 'tag' which
>>>>>>>>    I will introduce in the next version.
>>>>>>>>
>>>>>>>> -Takahiro Akashi
>>>>>>>>
>>>>>>>
>>>>>>> I don't know how this affect the code, but I agree with Akashi-san
>>>>>>> here.  It's indeed useful to keep the partition table stored
>>>>>>> somewhere,  but I think not showing them as part of the device tree is
>>>>>>> more intuitive.
>>>>>>
>>>>>> Well I think I'm easy either way. I just thought that Heinrich made a
>>>>>> good case for having a partition uclass.
>>>>>>
>>>>>> But as Takahiro says, we can use a tag to attach the partition table
>>>>>> to the device. But it should be attached to the device's children (the
>>>>>> BLK device) not the media device itself, right?
>>>>>
>>>>> As there has been no discussion in 5 days and Takahiro is writing
>>>>> this, let's go with no uclass for the partition table.
>>>>>
>>>>
>>>> Without uclass you cannot bring the partition table drivers into th driver model.
>>
>> This transition may be able to be done later when really necessary
>> as long as we agree that a partition table be hold within a "raw" disk
>> object (with a tag support).
>> # I don't think we need it for now.
>>
>>>> No clue what a tag should be in the driver model.
>>>
>>> A tag is a way to associate data with a device. At present we do this
>>> with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.)
>>> but with tags you can add something else.
>>
>> Since this discussion thread is getting too long, I would like
>> to respin my RFC. How should I deal with your "event notification"
>> proposal?
>
> Is the patch good enough to include in the series?
>
> If not, you could reply to it with what needs doing.
>
> Regards,
> Simon
>
The patch is not usable as is. It assumes only GPT partioning is used.

Instead all partition table drivers need to be converted to drivers for
the new uclass.

Best regards

Heinrich

AKASHI Takahiro Nov. 15, 2021, 11:51 p.m. UTC | #46

On Mon, Nov 15, 2021 at 08:16:25PM +0100, Heinrich Schuchardt wrote:
> On 11/15/21 20:05, Simon Glass wrote:
> > Hi Takahiro,
> > 
> > On Sun, 14 Nov 2021 at 18:43, AKASHI Takahiro
> > <takahiro.akashi@linaro.org> wrote:
> > > 
> > > Hi Simon,
> > > 
> > > On Sat, Nov 13, 2021 at 02:32:20PM -0700, Simon Glass wrote:
> > > > Hi Heinrich,
> > > > 
> > > > On Sat, 13 Nov 2021 at 11:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > > > 
> > > > > Am 13. November 2021 19:14:32 MEZ schrieb Simon Glass <sjg@chromium.org>:
> > > > > > Hi,
> > > > > > 
> > > > > > On Mon, 8 Nov 2021 at 17:09, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Mon, 8 Nov 2021 at 11:45, Ilias Apalodimas
> > > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > > > 
> > > > > > > > Hi chiming in a little late but
> > > > > > > > 
> > > > > > > > On Mon, 8 Nov 2021 at 06:46, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > > > > > > > 
> > > > > > > > > On Fri, Nov 05, 2021 at 10:12:16AM -0600, Simon Glass wrote:
> > > > > > > > > > Hi Takahiro,
> > > > > > > > > > 
> > > > > > > > > > On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 11/1/21 03:14, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Takahiro,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
> > > > > > > > > > > > > > <takahiro.akashi@linaro.org> 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
> > > > > > > > > > > > > > > > <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.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 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().
> > > > > > > > > > > 
> > > > > > > > > > > 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?
> > > > > > > > > 
> > > > > > > > > - First of all, a partition table doesn't look like a 'device' at all.
> > > > > > > > > - Second, a partition table is just static data for block devices.
> > > > > > > > >    IMO, even if we want to have this data, we can simply hold it
> > > > > > > > >    as some sort of attribute of the device, or maybe as a 'tag' which
> > > > > > > > >    I will introduce in the next version.
> > > > > > > > > 
> > > > > > > > > -Takahiro Akashi
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I don't know how this affect the code, but I agree with Akashi-san
> > > > > > > > here.  It's indeed useful to keep the partition table stored
> > > > > > > > somewhere,  but I think not showing them as part of the device tree is
> > > > > > > > more intuitive.
> > > > > > > 
> > > > > > > Well I think I'm easy either way. I just thought that Heinrich made a
> > > > > > > good case for having a partition uclass.
> > > > > > > 
> > > > > > > But as Takahiro says, we can use a tag to attach the partition table
> > > > > > > to the device. But it should be attached to the device's children (the
> > > > > > > BLK device) not the media device itself, right?
> > > > > > 
> > > > > > As there has been no discussion in 5 days and Takahiro is writing
> > > > > > this, let's go with no uclass for the partition table.
> > > > > > 
> > > > > 
> > > > > Without uclass you cannot bring the partition table drivers into th driver model.
> > > 
> > > This transition may be able to be done later when really necessary
> > > as long as we agree that a partition table be hold within a "raw" disk
> > > object (with a tag support).
> > > # I don't think we need it for now.
> > > 
> > > > > No clue what a tag should be in the driver model.
> > > > 
> > > > A tag is a way to associate data with a device. At present we do this
> > > > with varoius built-in mechanisms (priv data, uclass-priv, plat, etc.)
> > > > but with tags you can add something else.
> > > 
> > > Since this discussion thread is getting too long, I would like
> > > to respin my RFC. How should I deal with your "event notification"
> > > proposal?
> > 
> > Is the patch good enough to include in the series?
> > 
> > If not, you could reply to it with what needs doing.

? I have already replied to your patch :)
Basically, it seems to be fine to me.

> > Regards,
> > Simon
> > 
> The patch is not usable as is. It assumes only GPT partioning is used.

@Heinrich
I don't get your point. Either my patch or Simon's is not specific
to GPT at all.

So I'm going to start respinning my patch for a next round of discussion.

-Takahiro Akashi

> Instead all partition table drivers need to be converted to drivers for
> the new uclass.
> 
> Best regards
> 
> Heinrich

Heinrich Schuchardt Nov. 16, 2021, 12:02 a.m. UTC | #47

On 11/16/21 00:51, AKASHI Takahiro wrote:
>>> Is the patch good enough to include in the series?
>>>
>>> If not, you could reply to it with what needs doing.
> ? I have already replied to your patch:)
> Basically, it seems to be fine to me.
>
>>> Regards,
>>> Simon
>>>
>> The patch is not usable as is. It assumes only GPT partioning is used.
> @Heinrich
> I don't get your point. Either my patch or Simon's is not specific
> to GPT at all.
>
> So I'm going to start respinning my patch for a next round of discussion.

A field name gpt_part_info obviously relates to GPT?
Up to now this string exists only in cmd/gpt.c.

Best regards

Heinrich

>
> -Takahiro Akashi
>
>> Instead all partition table drivers need to be converted to drivers for
>> the new uclass.
>>
>> Best regards
>>
>> Heinrich

AKASHI Takahiro Nov. 16, 2021, 3:01 a.m. UTC | #48

On Tue, Nov 16, 2021 at 01:02:55AM +0100, Heinrich Schuchardt wrote:
> On 11/16/21 00:51, AKASHI Takahiro wrote:
> > > > Is the patch good enough to include in the series?
> > > > 
> > > > If not, you could reply to it with what needs doing.
> > ? I have already replied to your patch:)
> > Basically, it seems to be fine to me.
> > 
> > > > Regards,
> > > > Simon
> > > > 
> > > The patch is not usable as is. It assumes only GPT partioning is used.
> > @Heinrich
> > I don't get your point. Either my patch or Simon's is not specific
> > to GPT at all.
> > 
> > So I'm going to start respinning my patch for a next round of discussion.
> 
> A field name gpt_part_info obviously relates to GPT?

No.

IICU, the structure, disk_partition, is not particularly GPT-specific
as such type of data are used over various partition drivers.
In my patch series, I simply reuse "struct disk_part" as a structure
holding a partition number and partition information (= disk_partition).

-Takahiro Akashi

> Up to now this string exists only in cmd/gpt.c.
> 
> Best regards
> 
> Heinrich
> 
> > 
> > -Takahiro Akashi
> > 
> > > Instead all partition table drivers need to be converted to drivers for
> > > the new uclass.
> > > 
> > > Best regards
> > > 
> > > Heinrich
>

AKASHI Takahiro Dec. 3, 2021, 7:16 a.m. UTC | #49

Heinrich,

On Tue, Nov 16, 2021 at 12:01:27PM +0900, AKASHI Takahiro wrote:
> On Tue, Nov 16, 2021 at 01:02:55AM +0100, Heinrich Schuchardt wrote:
> > On 11/16/21 00:51, AKASHI Takahiro wrote:
> > > > > Is the patch good enough to include in the series?
> > > > > 
> > > > > If not, you could reply to it with what needs doing.
> > > ? I have already replied to your patch:)
> > > Basically, it seems to be fine to me.
> > > 
> > > > > Regards,
> > > > > Simon
> > > > > 
> > > > The patch is not usable as is. It assumes only GPT partioning is used.
> > > @Heinrich
> > > I don't get your point. Either my patch or Simon's is not specific
> > > to GPT at all.
> > > 
> > > So I'm going to start respinning my patch for a next round of discussion.
> > 
> > A field name gpt_part_info obviously relates to GPT?
> 
> No.
> 
> IICU, the structure, disk_partition, is not particularly GPT-specific
> as such type of data are used over various partition drivers.
> In my patch series, I simply reuse "struct disk_part" as a structure
> holding a partition number and partition information (= disk_partition).

So do you agree that we won't have "partition-table" devices for now?

-Takahiro Akashi


> -Takahiro Akashi
> 
> > Up to now this string exists only in cmd/gpt.c.
> > 
> > Best regards
> > 
> > Heinrich
> > 
> > > 
> > > -Takahiro Akashi
> > > 
> > > > Instead all partition table drivers need to be converted to drivers for
> > > > the new uclass.
> > > > 
> > > > Best regards
> > > > 
> > > > Heinrich
> >

Heinrich Schuchardt Dec. 3, 2021, 4:06 p.m. UTC | #50

On 12/3/21 08:16, AKASHI Takahiro wrote:
> Heinrich,
>
> On Tue, Nov 16, 2021 at 12:01:27PM +0900, AKASHI Takahiro wrote:
>> On Tue, Nov 16, 2021 at 01:02:55AM +0100, Heinrich Schuchardt wrote:
>>> On 11/16/21 00:51, AKASHI Takahiro wrote:
>>>>>> Is the patch good enough to include in the series?
>>>>>>
>>>>>> If not, you could reply to it with what needs doing.
>>>> ? I have already replied to your patch:)
>>>> Basically, it seems to be fine to me.
>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>> The patch is not usable as is. It assumes only GPT partioning is used.
>>>> @Heinrich
>>>> I don't get your point. Either my patch or Simon's is not specific
>>>> to GPT at all.
>>>>
>>>> So I'm going to start respinning my patch for a next round of discussion.
>>>
>>> A field name gpt_part_info obviously relates to GPT?
>>
>> No.
>>
>> IICU, the structure, disk_partition, is not particularly GPT-specific
>> as such type of data are used over various partition drivers.
>> In my patch series, I simply reuse "struct disk_part" as a structure
>> holding a partition number and partition information (= disk_partition).
>
> So do you agree that we won't have "partition-table" devices for now?
>
> -Takahiro Akashi

We don't need the partition-table to be a udevice now. We still can
later convert the partition drivers to a uclass if we deem it helpful.

Best regards

Heinrich

>
>
>> -Takahiro Akashi
>>
>>> Up to now this string exists only in cmd/gpt.c.
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>>>
>>>> -Takahiro Akashi
>>>>
>>>>> Instead all partition table drivers need to be converted to drivers for
>>>>> the new uclass.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Heinrich
>>>

AKASHI Takahiro Dec. 6, 2021, 4:18 a.m. UTC | #51

On Fri, Dec 03, 2021 at 05:06:56PM +0100, Heinrich Schuchardt wrote:
> On 12/3/21 08:16, AKASHI Takahiro wrote:
> > Heinrich,
> > 
> > On Tue, Nov 16, 2021 at 12:01:27PM +0900, AKASHI Takahiro wrote:
> > > On Tue, Nov 16, 2021 at 01:02:55AM +0100, Heinrich Schuchardt wrote:
> > > > On 11/16/21 00:51, AKASHI Takahiro wrote:
> > > > > > > Is the patch good enough to include in the series?
> > > > > > > 
> > > > > > > If not, you could reply to it with what needs doing.
> > > > > ? I have already replied to your patch:)
> > > > > Basically, it seems to be fine to me.
> > > > > 
> > > > > > > Regards,
> > > > > > > Simon
> > > > > > > 
> > > > > > The patch is not usable as is. It assumes only GPT partioning is used.
> > > > > @Heinrich
> > > > > I don't get your point. Either my patch or Simon's is not specific
> > > > > to GPT at all.
> > > > > 
> > > > > So I'm going to start respinning my patch for a next round of discussion.
> > > > 
> > > > A field name gpt_part_info obviously relates to GPT?
> > > 
> > > No.
> > > 
> > > IICU, the structure, disk_partition, is not particularly GPT-specific
> > > as such type of data are used over various partition drivers.
> > > In my patch series, I simply reuse "struct disk_part" as a structure
> > > holding a partition number and partition information (= disk_partition).
> > 
> > So do you agree that we won't have "partition-table" devices for now?
> > 
> > -Takahiro Akashi
> 
> We don't need the partition-table to be a udevice now. We still can
> later convert the partition drivers to a uclass if we deem it helpful.

OK. I'm going to prepare for next RFC.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> > 
> > > -Takahiro Akashi
> > > 
> > > > Up to now this string exists only in cmd/gpt.c.
> > > > 
> > > > Best regards
> > > > 
> > > > Heinrich
> > > > 
> > > > > 
> > > > > -Takahiro Akashi
> > > > > 
> > > > > > Instead all partition table drivers need to be converted to drivers for
> > > > > > the new uclass.
> > > > > > 
> > > > > > Best regards
> > > > > > 
> > > > > > Heinrich
> > > > 
>

diff mbox series

Patch

diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 83682dcc181a..dd7f3c0fe31e 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -12,6 +12,7 @@ 
 #include <log.h>
 #include <malloc.h>
 #include <part.h>
+#include <string.h>
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 #include <dm/uclass-internal.h>
@@ -695,6 +696,44 @@  int blk_unbind_all(int if_type)
 	return 0;
 }
 
+int blk_create_partitions(struct udevice *parent)
+{
+	int part, count;
+	struct blk_desc *desc = dev_get_uclass_plat(parent);
+	struct disk_partition info;
+	struct disk_part *part_data;
+	char devname[32];
+	struct udevice *dev;
+	int ret;
+
+	if (!CONFIG_IS_ENABLED(PARTITIONS) ||
+	    !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
+		return 0;
+
+	/* Add devices for each partition */
+	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+		if (part_get_info(desc, part, &info))
+			continue;
+		snprintf(devname, sizeof(devname), "%s:%d", parent->name,
+			 part);
+
+		ret = device_bind_driver(parent, "blk_partition",
+					 strdup(devname), &dev);
+		if (ret)
+			return ret;
+
+		part_data = dev_get_uclass_plat(dev);
+		part_data->partnum = part;
+		part_data->gpt_part_info = info;
+		count++;
+
+		device_probe(dev);
+	}
+	debug("%s: %d partitions found in %s\n", __func__, count, parent->name);
+
+	return 0;
+}
+
 static int blk_post_probe(struct udevice *dev)
 {
 	if (IS_ENABLED(CONFIG_PARTITIONS) &&
@@ -713,3 +752,75 @@  UCLASS_DRIVER(blk) = {
 	.post_probe	= blk_post_probe,
 	.per_device_plat_auto	= sizeof(struct blk_desc),
 };
+
+static ulong blk_part_read(struct udevice *dev, lbaint_t start,
+			   lbaint_t blkcnt, void *buffer)
+{
+	struct udevice *parent;
+	struct disk_part *part;
+	const struct blk_ops *ops;
+
+	parent = dev_get_parent(dev);
+	ops = blk_get_ops(parent);
+	if (!ops->read)
+		return -ENOSYS;
+
+	part = dev_get_uclass_plat(dev);
+	start += part->gpt_part_info.start;
+
+	return ops->read(parent, start, blkcnt, buffer);
+}
+
+static ulong blk_part_write(struct udevice *dev, lbaint_t start,
+			    lbaint_t blkcnt, const void *buffer)
+{
+	struct udevice *parent;
+	struct disk_part *part;
+	const struct blk_ops *ops;
+
+	parent = dev_get_parent(dev);
+	ops = blk_get_ops(parent);
+	if (!ops->write)
+		return -ENOSYS;
+
+	part = dev_get_uclass_plat(dev);
+	start += part->gpt_part_info.start;
+
+	return ops->write(parent, start, blkcnt, buffer);
+}
+
+static ulong blk_part_erase(struct udevice *dev, lbaint_t start,
+			    lbaint_t blkcnt)
+{
+	struct udevice *parent;
+	struct disk_part *part;
+	const struct blk_ops *ops;
+
+	parent = dev_get_parent(dev);
+	ops = blk_get_ops(parent);
+	if (!ops->erase)
+		return -ENOSYS;
+
+	part = dev_get_uclass_plat(dev);
+	start += part->gpt_part_info.start;
+
+	return ops->erase(parent, start, blkcnt);
+}
+
+static const struct blk_ops blk_part_ops = {
+	.read	= blk_part_read,
+	.write	= blk_part_write,
+	.erase	= blk_part_erase,
+};
+
+U_BOOT_DRIVER(blk_partition) = {
+	.name		= "blk_partition",
+	.id		= UCLASS_PARTITION,
+	.ops		= &blk_part_ops,
+};
+
+UCLASS_DRIVER(partition) = {
+	.id		= UCLASS_PARTITION,
+	.per_device_plat_auto	= sizeof(struct disk_part),
+	.name		= "partition",
+};
diff --git a/include/blk.h b/include/blk.h
index 19bab081c2cd..3d883eb1db64 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -366,6 +366,15 @@  int blk_create_devicef(struct udevice *parent, const char *drv_name,
 		       const char *name, int if_type, int devnum, int blksz,
 		       lbaint_t lba, struct udevice **devp);
 
+/**
+ * blk_create_partitions - Create block devices for disk partitions
+ *
+ * Create UCLASS_PARTITION udevices for each of disk partitions in @parent
+ *
+ * @parent:	Whole disk device
+ */
+int blk_create_partitions(struct udevice *parent);
+
 /**
  * blk_unbind_all() - Unbind all device of the given interface type
  *
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index e7edd409f307..30892d01ce13 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -80,6 +80,7 @@  enum uclass_id {
 	UCLASS_P2SB,		/* (x86) Primary-to-Sideband Bus */
 	UCLASS_PANEL,		/* Display panel, such as an LCD */
 	UCLASS_PANEL_BACKLIGHT,	/* Backlight controller for panel */
+	UCLASS_PARTITION,	/* Logical disk partition device */
 	UCLASS_PCH,		/* x86 platform controller hub */
 	UCLASS_PCI,		/* PCI bus */
 	UCLASS_PCI_EP,		/* PCI endpoint device */