LinuxLists.cc - [PATCH] block: support embedded device command line partition

[permalink] [raw]

Subject: Re: [PATCH] block: support embedded device command line partition

On Sat, 3 Aug 2013 09:57:04 +0000 Caizhiyong <[email protected]> wrote:

> From: Cai Zhiyong <[email protected]>
>
> Read block device partition table from command line.
> The partition used for fixed block device (eMMC) embedded device.
> It is no MBR, save storage space. Bootloader can be easily accessed by
> absolute address of data on the block device.
> Users can easily change the partition.
>
> This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
> About the partition verbose reference "Documentation/block/cmdline-partition.txt"
>

Seems OK to me.

The obvious question is: can we consolidate this with
drivers/mtd/cmdlinepart.c in some fashion so the kernel doesn't have
two parsers which do the same thing?

2013-08-06 10:56:00

[permalink] [raw]

Subject: RE: [PATCH] block: support embedded device command line partition

> -----Original Message-----
> From: Andrew Morton [mailto:[email protected]]
> Sent: Tuesday, August 06, 2013 6:22 AM
> To: Caizhiyong
> Cc: Karel Zak; [email protected]; Wanglin (Albert); Quyaxin; Jens Axboe;
> David Woodhouse; Marius Groeger
> Subject: Re: [PATCH] block: support embedded device command line partition
>
> On Sat, 3 Aug 2013 09:57:04 +0000 Caizhiyong <[email protected]> wrote:
>
> > From: Cai Zhiyong <[email protected]>
> >
> > Read block device partition table from command line.
> > The partition used for fixed block device (eMMC) embedded device.
> > It is no MBR, save storage space. Bootloader can be easily accessed by
> > absolute address of data on the block device.
> > Users can easily change the partition.
> >
> > This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
> > About the partition verbose reference
> "Documentation/block/cmdline-partition.txt"
> >
>
> Seems OK to me.
>
> The obvious question is: can we consolidate this with
> drivers/mtd/cmdlinepart.c in some fashion so the kernel doesn't have
> two parsers which do the same thing?

I will move the parser to "lib/cmdline.c".

Looking forward to your feedback.
Best regards,
Cai Zhiyong.

http://www.huawei.com

2013-08-07 00:11:50

[permalink] [raw]

Subject: Re: [PATCH] block: support embedded device command line partition

On Tue, 6 Aug 2013 10:53:01 +0000 Caizhiyong <[email protected]> wrote:

> > -----Original Message-----
> > From: Andrew Morton [mailto:[email protected]]
> > Sent: Tuesday, August 06, 2013 6:22 AM
> > To: Caizhiyong
> > Cc: Karel Zak; [email protected]; Wanglin (Albert); Quyaxin; Jens Axboe;
> > David Woodhouse; Marius Groeger
> > Subject: Re: [PATCH] block: support embedded device command line partition
> >
> > On Sat, 3 Aug 2013 09:57:04 +0000 Caizhiyong <[email protected]> wrote:
> >
> > > From: Cai Zhiyong <[email protected]>
> > >
> > > Read block device partition table from command line.
> > > The partition used for fixed block device (eMMC) embedded device.
> > > It is no MBR, save storage space. Bootloader can be easily accessed by
> > > absolute address of data on the block device.
> > > Users can easily change the partition.
> > >
> > > This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
> > > About the partition verbose reference
> > "Documentation/block/cmdline-partition.txt"
> > >
> >
> > Seems OK to me.
> >
> > The obvious question is: can we consolidate this with
> > drivers/mtd/cmdlinepart.c in some fashion so the kernel doesn't have
> > two parsers which do the same thing?
>
> I will move the parser to "lib/cmdline.c".
>

block/cmdline.c is an appropriate place for block-subsystem library
code.

But simply moving the file doesn't achieve anything. To prove that the
code is indeed library-style code, we should actually *use* it in some
client code. Such as MTD!

2013-08-13 06:02:35

[permalink] [raw]

Subject: [PATCH] block: add command line partition parser

From: Cai Zhiyong <[email protected]>

move the command line parser to a separate module, and change it into
library-style code.

reference: https://lkml.org/lkml/2013/8/6/550

Signed-off-by: Cai Zhiyong <[email protected]>
---
block/Kconfig | 6 +
block/Makefile | 1 +
block/cmdline-parser.c | 249 +++++++++++++++++++++++++++++++++
block/partitions/Kconfig | 1 +
block/partitions/cmdline.c | 311 ++++++-----------------------------------
include/linux/cmdline-parser.h | 43 ++++++
6 files changed, 342 insertions(+), 269 deletions(-)
create mode 100644 block/cmdline-parser.c
create mode 100644 include/linux/cmdline-parser.h

diff --git a/block/Kconfig b/block/Kconfig
index a7e40a7..7f38e40 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -99,6 +99,12 @@ config BLK_DEV_THROTTLING

See Documentation/cgroups/blkio-controller.txt for more information.

+config CMDLINE_PARSER
+ bool "Block device command line partition parser"
+ default n
+ ---help---
+ Parsing command line, get the partitions information.
+
menu "Partition Types"

source "block/partitions/Kconfig"
diff --git a/block/Makefile b/block/Makefile
index 39b76ba..4fa4be5 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched.o

obj-$(CONFIG_BLOCK_COMPAT) += compat_ioctl.o
obj-$(CONFIG_BLK_DEV_INTEGRITY) += blk-integrity.o
+obj-$(CONFIG_CMDLINE_PARSER) += cmdline-parser.o
diff --git a/block/cmdline-parser.c b/block/cmdline-parser.c
new file mode 100644
index 0000000..18fb435
--- /dev/null
+++ b/block/cmdline-parser.c
@@ -0,0 +1,249 @@
+/*
+ * Parse command line, get partition information
+ *
+ * Written by Cai Zhiyong <[email protected]>
+ *
+ */
+#include <linux/buffer_head.h>
+#include <linux/module.h>
+#include <linux/cmdline-parser.h>
+
+static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
+{
+ int ret = 0;
+ struct cmdline_subpart *new_subpart;
+
+ *subpart = NULL;
+
+ new_subpart = kzalloc(sizeof(struct cmdline_subpart), GFP_KERNEL);
+ if (!new_subpart)
+ return -ENOMEM;
+
+ if (*partdef == '-') {
+ new_subpart->size = (sector_t)(~0ULL);
+ partdef++;
+ } else {
+ new_subpart->size = (sector_t)memparse(partdef, &partdef);
+ if (new_subpart->size < (sector_t)PAGE_SIZE) {
+ pr_warn("cmdline partition size is invalid.");
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ if (*partdef == '@') {
+ partdef++;
+ new_subpart->from = (sector_t)memparse(partdef, &partdef);
+ } else {
+ new_subpart->from = (sector_t)(~0ULL);
+ }
+
+ if (*partdef == '(') {
+ int length;
+ char *next = strchr(++partdef, ')');
+
+ if (!next) {
+ pr_warn("cmdline partition format is invalid.");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ length = min_t(int, next - partdef,
+ sizeof(new_subpart->name) - 1);
+ strncpy(new_subpart->name, partdef, length);
+ new_subpart->name[length] = '\0';
+
+ partdef = ++next;
+ } else
+ new_subpart->name[0] = '\0';
+
+ new_subpart->flags = 0;
+
+ if (!strncmp(partdef, "ro", 2)) {
+ new_subpart->flags |= PF_RDONLY;
+ partdef += 2;
+ }
+
+ if (!strncmp(partdef, "lk", 2)) {
+ new_subpart->flags |= PF_POWERUP_LOCK;
+ partdef += 2;
+ }
+
+ *subpart = new_subpart;
+ return 0;
+fail:
+ kfree(new_subpart);
+ return ret;
+}
+
+static void free_subpart(struct cmdline_parts *parts)
+{
+ struct cmdline_subpart *subpart;
+
+ while (parts->subpart) {
+ subpart = parts->subpart;
+ parts->subpart = subpart->next_subpart;
+ kfree(subpart);
+ }
+}
+
+static int parse_parts(struct cmdline_parts **parts, const char *bdevdef)
+{
+ int ret = -EINVAL;
+ char *next;
+ int length;
+ struct cmdline_subpart **next_subpart;
+ struct cmdline_parts *newparts;
+ char buf[BDEVNAME_SIZE + 32 + 4];
+
+ *parts = NULL;
+
+ newparts = kzalloc(sizeof(struct cmdline_parts), GFP_KERNEL);
+ if (!newparts)
+ return -ENOMEM;
+
+ next = strchr(bdevdef, ':');
+ if (!next) {
+ pr_warn("cmdline partition has no block device.");
+ goto fail;
+ }
+
+ length = min_t(int, next - bdevdef, sizeof(newparts->name) - 1);
+ strncpy(newparts->name, bdevdef, length);
+ newparts->name[length] = '\0';
+ newparts->nr_subparts = 0;
+
+ next_subpart = &newparts->subpart;
+
+ while (next && *(++next)) {
+ bdevdef = next;
+ next = strchr(bdevdef, ',');
+
+ length = (!next) ? (sizeof(buf) - 1) :
+ min_t(int, next - bdevdef, sizeof(buf) - 1);
+
+ strncpy(buf, bdevdef, length);
+ buf[length] = '\0';
+
+ ret = parse_subpart(next_subpart, buf);
+ if (ret)
+ goto fail;
+
+ newparts->nr_subparts++;
+ next_subpart = &(*next_subpart)->next_subpart;
+ }
+
+ if (!newparts->subpart) {
+ pr_warn("cmdline partition has no valid partition.");
+ goto fail;
+ }
+
+ *parts = newparts;
+
+ return 0;
+fail:
+ free_subpart(newparts);
+ kfree(newparts);
+ return ret;
+}
+
+void cmdline_parts_free(struct cmdline_parts **parts)
+{
+ struct cmdline_parts *next_parts;
+
+ while (*parts) {
+ next_parts = (*parts)->next_parts;
+ free_subpart(*parts);
+ kfree(*parts);
+ *parts = next_parts;
+ }
+}
+
+int cmdline_parts_parse(struct cmdline_parts **parts, const char *cmdline)
+{
+ int ret;
+ char *buf;
+ char *pbuf;
+ char *next;
+ struct cmdline_parts **next_parts;
+
+ *parts = NULL;
+
+ next = pbuf = buf = kstrdup(cmdline, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ next_parts = parts;
+
+ while (next && *pbuf) {
+ next = strchr(pbuf, ';');
+ if (next)
+ *next = '\0';
+
+ ret = parse_parts(next_parts, pbuf);
+ if (ret)
+ goto fail;
+
+ if (next)
+ pbuf = ++next;
+
+ next_parts = &(*next_parts)->next_parts;
+ }
+
+ if (!*parts) {
+ pr_warn("cmdline partition has no valid partition.");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ ret = 0;
+done:
+ kfree(buf);
+ return ret;
+
+fail:
+ cmdline_parts_free(parts);
+ goto done;
+}
+
+struct cmdline_parts *cmdline_parts_find(struct cmdline_parts *parts,
+ const char *bdev)
+{
+ while (parts && strncmp(bdev, parts->name, sizeof(parts->name)))
+ parts = parts->next_parts;
+ return parts;
+}
+
+/*
+ * add_part()
+ * 0 success.
+ * 1 can not add so many partitions.
+ */
+void cmdline_parts_set(struct cmdline_parts *parts, sector_t disk_size,
+ int slot,
+ int (*add_part)(int, struct cmdline_subpart *, void *),
+ void *param)
+
+{
+ sector_t from = 0;
+ struct cmdline_subpart *subpart;
+
+ for (subpart = parts->subpart; subpart;
+ subpart = subpart->next_subpart, slot++) {
+ if (subpart->from == (sector_t)(~0ULL))
+ subpart->from = from;
+ else
+ from = subpart->from;
+
+ if (from >= disk_size)
+ break;
+
+ if (subpart->size > (disk_size - from))
+ subpart->size = disk_size - from;
+
+ from += subpart->size;
+
+ if (add_part(slot, subpart, param))
+ break;
+ }
+}
diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig
index 2ebf251..87a3208 100644
--- a/block/partitions/Kconfig
+++ b/block/partitions/Kconfig
@@ -263,6 +263,7 @@ config SYSV68_PARTITION

config CMDLINE_PARTITION
bool "Command line partition support" if PARTITION_ADVANCED
+ select CMDLINE_PARSER
help
Say Y here if you would read the partitions table from bootargs.
The format for the command line is just like mtdparts.
diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c
index 1a1eac7..56cf4ff 100644
--- a/block/partitions/cmdline.c
+++ b/block/partitions/cmdline.c
@@ -8,219 +8,54 @@
* by absolute address of data on the block device.
* Users can easily change the partition.
*
- * This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
* The format for the command line is just like mtdparts.
*
* Verbose config please reference "Documentation/block/cmdline-partition.txt"
*
*/

-#include <linux/buffer_head.h>
-#include <linux/module.h>
-#include <linux/ctype.h>
+#include <linux/cmdline-parser.h>

#include "check.h"
#include "cmdline.h"

-struct cmdline_subpart {
- char name[BDEVNAME_SIZE]; /* partition name, such as 'rootfs' */
- sector_t from;
- sector_t size;
- struct cmdline_subpart *next_subpart;
-};
+static char *cmdline;
+static struct cmdline_parts *bdev_parts;

-struct cmdline_parts {
- char name[BDEVNAME_SIZE]; /* block device, such as 'mmcblk0' */
- struct cmdline_subpart *subpart;
- struct cmdline_parts *next_parts;
-};
-
-static char *cmdline_string;
-static struct cmdline_parts *cmdline_parts;
-
-static int parse_subpart(struct cmdline_subpart **subpart, char *cmdline)
-{
- int ret = 0;
- struct cmdline_subpart *new_subpart;
-
- *subpart = NULL;
-
- new_subpart = kzalloc(sizeof(struct cmdline_subpart), GFP_KERNEL);
- if (!new_subpart)
- return -ENOMEM;
-
- if (*cmdline == '-') {
- new_subpart->size = (sector_t)(~0ULL);
- cmdline++;
- } else {
- new_subpart->size = (sector_t)memparse(cmdline, &cmdline);
- if (new_subpart->size < (sector_t)PAGE_SIZE) {
- pr_warn("cmdline partition size is invalid.");
- ret = -EINVAL;
- goto fail;
- }
- }
-
- if (*cmdline == '@') {
- cmdline++;
- new_subpart->from = (sector_t)memparse(cmdline, &cmdline);
- } else {
- new_subpart->from = (sector_t)(~0ULL);
- }
-
- if (*cmdline == '(') {
- int length;
- char *next = strchr(++cmdline, ')');
-
- if (!next) {
- pr_warn("cmdline partition format is invalid.");
- ret = -EINVAL;
- goto fail;
- }
-
- length = min_t(int, next - cmdline,
- sizeof(new_subpart->name) - 1);
- strncpy(new_subpart->name, cmdline, length);
- new_subpart->name[length] = '\0';
-
- cmdline = ++next;
- } else
- new_subpart->name[0] = '\0';
-
- *subpart = new_subpart;
- return 0;
-fail:
- kfree(new_subpart);
- return ret;
-}
-
-static void free_subpart(struct cmdline_parts *parts)
-{
- struct cmdline_subpart *subpart;
-
- while (parts->subpart) {
- subpart = parts->subpart;
- parts->subpart = subpart->next_subpart;
- kfree(subpart);
- }
-}
-
-static void free_parts(struct cmdline_parts **parts)
-{
- struct cmdline_parts *next_parts;
-
- while (*parts) {
- next_parts = (*parts)->next_parts;
- free_subpart(*parts);
- kfree(*parts);
- *parts = next_parts;
- }
-}
-
-static int parse_parts(struct cmdline_parts **parts, const char *cmdline)
+static int add_part(int slot, struct cmdline_subpart *subpart, void *param)
{
- int ret = -EINVAL;
- char *next;
- int length;
- struct cmdline_subpart **next_subpart;
- struct cmdline_parts *newparts;
- char buf[BDEVNAME_SIZE + 32 + 4];
+ int label_min;
+ struct partition_meta_info *info;
+ char tmp[sizeof(info->volname) + 4];
+ struct parsed_partitions *state = (struct parsed_partitions *)param;

- *parts = NULL;
+ if (slot >= state->limit)
+ return 1;

- newparts = kzalloc(sizeof(struct cmdline_parts), GFP_KERNEL);
- if (!newparts)
- return -ENOMEM;
+ put_partition(state, slot, subpart->from >> 9,
+ subpart->size >> 9);

- next = strchr(cmdline, ':');
- if (!next) {
- pr_warn("cmdline partition has no block device.");
- goto fail;
- }
-
- length = min_t(int, next - cmdline, sizeof(newparts->name) - 1);
- strncpy(newparts->name, cmdline, length);
- newparts->name[length] = '\0';
-
- next_subpart = &newparts->subpart;
+ info = &state->parts[slot].info;

- while (next && *(++next)) {
- cmdline = next;
- next = strchr(cmdline, ',');
+ label_min = min_t(int, sizeof(info->volname) - 1,
+ sizeof(subpart->name));
+ strncpy(info->volname, subpart->name, label_min);
+ info->volname[label_min] = '\0';

- length = (!next) ? (sizeof(buf) - 1) :
- min_t(int, next - cmdline, sizeof(buf) - 1);
+ snprintf(tmp, sizeof(tmp), "(%s)", info->volname);
+ strlcat(state->pp_buf, tmp, PAGE_SIZE);

- strncpy(buf, cmdline, length);
- buf[length] = '\0';
-
- ret = parse_subpart(next_subpart, buf);
- if (ret)
- goto fail;
-
- next_subpart = &(*next_subpart)->next_subpart;
- }
-
- if (!newparts->subpart) {
- pr_warn("cmdline partition has no valid partition.");
- goto fail;
- }
-
- *parts = newparts;
+ state->parts[slot].has_info = true;

return 0;
-fail:
- free_subpart(newparts);
- kfree(newparts);
- return ret;
}

-static int parse_cmdline(struct cmdline_parts **parts, const char *cmdline)
+static int __init cmdline_parts_setup(char *s)
{
- int ret;
- char *buf;
- char *pbuf;
- char *next;
- struct cmdline_parts **next_parts;
-
- *parts = NULL;
-
- next = pbuf = buf = kstrdup(cmdline, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
- next_parts = parts;
-
- while (next && *pbuf) {
- next = strchr(pbuf, ';');
- if (next)
- *next = '\0';
-
- ret = parse_parts(next_parts, pbuf);
- if (ret)
- goto fail;
-
- if (next)
- pbuf = ++next;
-
- next_parts = &(*next_parts)->next_parts;
- }
-
- if (!*parts) {
- pr_warn("cmdline partition has no valid partition.");
- ret = -EINVAL;
- goto fail;
- }
-
- ret = 0;
-done:
- kfree(buf);
- return ret;
-
-fail:
- free_parts(parts);
- goto done;
+ cmdline = s;
+ return 1;
}
+__setup("blkdevparts=", cmdline_parts_setup);

/*
* Purpose: allocate cmdline partitions.
@@ -229,98 +64,36 @@ fail:
* 0 if this isn't our partition table
* 1 if successful
*/
-static int parse_partitions(struct parsed_partitions *state,
- struct cmdline_parts *parts)
+int cmdline_partition(struct parsed_partitions *state)
{
- int slot;
- sector_t from = 0;
sector_t disk_size;
- char buf[BDEVNAME_SIZE];
- struct cmdline_subpart *subpart;
+ char bdev[BDEVNAME_SIZE];
+ struct cmdline_parts *parts;
+
+ if (cmdline) {
+ if (bdev_parts)
+ cmdline_parts_free(&bdev_parts);

- bdevname(state->bdev, buf);
+ if (cmdline_parts_parse(&bdev_parts, cmdline)) {
+ cmdline = NULL;
+ return -1;
+ }
+ cmdline = NULL;
+ }

- while (parts && strncmp(buf, parts->name, BDEVNAME_SIZE))
- parts = parts->next_parts;
+ if (!bdev_parts)
+ return 0;

+ bdevname(state->bdev, bdev);
+ parts = cmdline_parts_find(bdev_parts, bdev);
if (!parts)
return 0;

disk_size = get_capacity(state->bdev->bd_disk) << 9;

- for (slot = 1, subpart = parts->subpart;
- subpart && slot < state->limit;
- subpart = subpart->next_subpart, slot++) {
- int label_min;
- struct partition_meta_info *info;
- char tmp[sizeof(info->volname) + 4];
-
- if (subpart->from == (sector_t)(~0ULL))
- subpart->from = from;
- else
- from = subpart->from;
-
- if (from >= disk_size)
- break;
-
- if (subpart->size > (disk_size - from))
- subpart->size = disk_size - from;
-
- from += subpart->size;
-
- put_partition(state, slot, subpart->from >> 9,
- subpart->size >> 9);
-
- info = &state->parts[slot].info;
-
- label_min = min_t(int, sizeof(info->volname) - 1,
- sizeof(subpart->name));
- strncpy(info->volname, subpart->name, label_min);
- info->volname[label_min] = '\0';
-
- snprintf(tmp, sizeof(tmp), "(%s)", info->volname);
- strlcat(state->pp_buf, tmp, PAGE_SIZE);
-
- state->parts[slot].has_info = true;
- }
+ cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);

strlcat(state->pp_buf, "\n", PAGE_SIZE);

return 1;
}
-
-static int __init cmdline_parts_setup(char *s)
-{
- cmdline_string = s;
- return 1;
-}
-__setup("blkdevparts=", cmdline_parts_setup);
-
-/*
- * Purpose: allocate cmdline partitions.
- * Returns:
- * -1 if unable to read the partition table
- * 0 if this isn't our partition table
- * 1 if successful
- */
-int cmdline_partition(struct parsed_partitions *state)
-{
- if (cmdline_string) {
- if (cmdline_parts)
- free_parts(&cmdline_parts);
-
- if (parse_cmdline(&cmdline_parts, cmdline_string))
- goto fail;
-
- cmdline_string = NULL;
- }
-
- if (!cmdline_parts)
- return 0;
-
- return parse_partitions(state, cmdline_parts);
-
-fail:
- cmdline_string = NULL;
- return -1;
-}
diff --git a/include/linux/cmdline-parser.h b/include/linux/cmdline-parser.h
new file mode 100644
index 0000000..98e892e
--- /dev/null
+++ b/include/linux/cmdline-parser.h
@@ -0,0 +1,43 @@
+/*
+ * Parsing command line, get the partitions information.
+ *
+ * Written by Cai Zhiyong <[email protected]>
+ *
+ */
+#ifndef CMDLINEPARSEH
+#define CMDLINEPARSEH
+
+#include <linux/blkdev.h>
+
+/* partition flags */
+#define PF_RDONLY 0x01 /* Device is read only */
+#define PF_POWERUP_LOCK 0x02 /* Always locked after reset */
+
+struct cmdline_subpart {
+ char name[BDEVNAME_SIZE]; /* partition name, such as 'rootfs' */
+ sector_t from;
+ sector_t size;
+ int flags;
+ struct cmdline_subpart *next_subpart;
+};
+
+struct cmdline_parts {
+ char name[BDEVNAME_SIZE]; /* block device, such as 'mmcblk0' */
+ unsigned int nr_subparts;
+ struct cmdline_subpart *subpart;
+ struct cmdline_parts *next_parts;
+};
+
+void cmdline_parts_free(struct cmdline_parts **parts);
+
+int cmdline_parts_parse(struct cmdline_parts **parts, const char *cmdline);
+
+struct cmdline_parts *cmdline_parts_find(struct cmdline_parts *parts,
+ const char *bdev);
+
+void cmdline_parts_set(struct cmdline_parts *parts, sector_t disk_size,
+ int slot,
+ int (*add_part)(int, struct cmdline_subpart *, void *),
+ void *param);
+
+#endif /* CMDLINEPARSEH */
--
1.8.1.5

2013-08-14 22:57:44

[permalink] [raw]

Subject: Re: [PATCH] block: add command line partition parser

On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:

> move the command line parser to a separate module, and change it into
> library-style code.
>
> reference: https://lkml.org/lkml/2013/8/6/550

Well OK. But to prove the library's usefulness and to generally clean
up the kernel, someone needs to sign up to the task of converting
drivers/mtd/cmdlinepart.c to use this code.

I've been hopefully cc'ing various MTD people but am not being
overwhelmed with waves of enthusiasm ;)

2013-08-15 00:11:54

[permalink] [raw]

Subject: Re: [PATCH] block: add command line partition parser

On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
<[email protected]> wrote:
> On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:
>
>> move the command line parser to a separate module, and change it into
>> library-style code.
>>
>> reference: https://lkml.org/lkml/2013/8/6/550

The most recent patch is an addendum to this linked patch then?

> Well OK. But to prove the library's usefulness and to generally clean
> up the kernel, someone needs to sign up to the task of converting
> drivers/mtd/cmdlinepart.c to use this code.
>
> I've been hopefully cc'ing various MTD people but am not being
> overwhelmed with waves of enthusiasm ;)

"I've been" implies that you have done so prior to this email. And
"people" implies more than one person. I see that you CC'd David
Woodhouse over a week ago, but he's fairly silent these days on MTD
things. It's Artem or me who handle most of the day-to-day of MTD. And
this is the first time I've seen this! (BTW, please include
[email protected] for anything involving MTD.)

This seems reasonable, and I'd be willing to work with this proposal.

Caizhiyong, can you submit a clear single patch (or series of
patches), CC'd to linux-mtd at least? Then we can see about supporting
it in MTD. It doesn't look too difficult, but I need to check that it
faithfully mimics the capability we currently rely on. There have been
previous discussions on changing it, but this was rejected in favor of
allowing more flexibility. Here's part of one such conversation:

http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html

So I would recommend:
(1) consider carefully the implications of your command-line format
now, rather than later
(2) if you want MTD to use it, it needs to support the features we use now

Some particular cases to consider: overlapping partitions (how do
block devices handle overlapping partitions?), out-of-order
specification, zero sized partitions, mixed syntax (some specified
with an offset, some not), multiple '-' partitions.

Anyway, if you resend, we can review.

Thanks,
Brian

2013-08-15 00:32:43

[permalink] [raw]

Subject: Re: [PATCH] block: add command line partition parser

On Wed, 14 Aug 2013 17:11:51 -0700 Brian Norris <[email protected]> wrote:

> On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> <[email protected]> wrote:
> > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:
> >
> >> move the command line parser to a separate module, and change it into
> >> library-style code.
> >>
> >> reference: https://lkml.org/lkml/2013/8/6/550
>
> The most recent patch is an addendum to this linked patch then?

The unifed latest version is appended.

> > Well OK. But to prove the library's usefulness and to generally clean
> > up the kernel, someone needs to sign up to the task of converting
> > drivers/mtd/cmdlinepart.c to use this code.
> >
> > I've been hopefully cc'ing various MTD people but am not being
> > overwhelmed with waves of enthusiasm ;)
>
> "I've been" implies that you have done so prior to this email. And
> "people" implies more than one person. I see that you CC'd David
> Woodhouse over a week ago, but he's fairly silent these days on MTD
> things. It's Artem or me who handle most of the day-to-day of MTD. And
> this is the first time I've seen this! (BTW, please include
> [email protected] for anything involving MTD.)
>
> This seems reasonable, and I'd be willing to work with this proposal.

Thanks.

> Caizhiyong, can you submit a clear single patch (or series of
> patches), CC'd to linux-mtd at least? Then we can see about supporting
> it in MTD. It doesn't look too difficult, but I need to check that it
> faithfully mimics the capability we currently rely on. There have been
> previous discussions on changing it, but this was rejected in favor of
> allowing more flexibility. Here's part of one such conversation:
>
> http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
>
> So I would recommend:
> (1) consider carefully the implications of your command-line format
> now, rather than later
> (2) if you want MTD to use it, it needs to support the features we use now
>
> Some particular cases to consider: overlapping partitions (how do
> block devices handle overlapping partitions?), out-of-order
> specification, zero sized partitions, mixed syntax (some specified
> with an offset, some not), multiple '-' partitions.

This patch is still at the review-and-under-test stage so now is a fine
time to make changes.

> Anyway, if you resend, we can review.

From: Cai Zhiyong <[email protected]>
Subject: block: support embedded device command line partition

Read block device partition table from command line. The partition used
for fixed block device (eMMC) embedded device. It is no MBR, save storage
space. Bootloader can be easily accessed by absolute address of data on
the block device. Users can easily change the partition.

This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
About the partition verbose reference
"Documentation/block/cmdline-partition.txt"

[[email protected]: fix printk text]
Signed-off-by: Cai Zhiyong <[email protected]>
Cc: Karel Zak <[email protected]>
Cc: "Wanglin (Albert)" <[email protected]>
Cc: Marius Groeger <[email protected]>
Cc: David Woodhouse <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Artem Bityutskiy <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

Documentation/block/cmdline-partition.txt | 40 +++
block/Kconfig | 6
block/Makefile | 1
block/cmdline-parser.c | 249 ++++++++++++++++++++
block/partitions/Kconfig | 7
block/partitions/Makefile | 1
block/partitions/check.c | 4
block/partitions/cmdline.c | 99 +++++++
block/partitions/cmdline.h | 2
include/linux/cmdline-parser.h | 43 +++
10 files changed, 452 insertions(+)

diff -puN /dev/null Documentation/block/cmdline-partition.txt
--- /dev/null
+++ a/Documentation/block/cmdline-partition.txt
@@ -0,0 +1,40 @@
+Embedded device command line partition
+=====================================================================
+
+Read block device partition table from command line.
+The partition used for fixed block device (eMMC) embedded device.
+It is no MBR, save storage space. Bootloader can be easily accessed
+by absolute address of data on the block device.
+Users can easily change the partition.
+
+The format for the command line is just like mtdparts:
+
+blkdevparts=<blkdev-def>[;<blkdev-def>]
+ <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
+ <partdef> := <size>[@<offset>](part-name)
+
+<blkdev-id>
+ block device disk name, embedded device used fixed block device,
+ it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
+
+<size>
+ partition size, in bytes, such as: 512, 1m, 1G.
+
+<offset>
+ partition start address, in bytes.
+
+(part-name)
+ partition name, kernel send uevent with "PARTNAME". application can create
+ a link to block device partition with the name "PARTNAME".
+ user space application can access partition by partition name.
+
+Example:
+ eMMC disk name is "mmcblk0" and "mmcblk0boot0"
+
+ bootargs:
+ 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
+
+ dmesg:
+ mmcblk0: p1(data0) p2(data1) p3()
+ mmcblk0boot0: p1(boot) p2(kernel)
+
diff -puN block/partitions/Kconfig~block-support-embedded-device-command-line-partition block/partitions/Kconfig
--- a/block/partitions/Kconfig~block-support-embedded-device-command-line-partition
+++ a/block/partitions/Kconfig
@@ -260,3 +260,10 @@ config SYSV68_PARTITION
partition table format used by Motorola Delta machines (using
sysv68).
Otherwise, say N.
+
+config CMDLINE_PARTITION
+ bool "Command line partition support" if PARTITION_ADVANCED
+ select CMDLINE_PARSER
+ help
+ Say Y here if you would read the partitions table from bootargs.
+ The format for the command line is just like mtdparts.
diff -puN block/partitions/Makefile~block-support-embedded-device-command-line-partition block/partitions/Makefile
--- a/block/partitions/Makefile~block-support-embedded-device-command-line-partition
+++ a/block/partitions/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ACORN_PARTITION) += acorn.o
obj-$(CONFIG_AMIGA_PARTITION) += amiga.o
obj-$(CONFIG_ATARI_PARTITION) += atari.o
obj-$(CONFIG_AIX_PARTITION) += aix.o
+obj-$(CONFIG_CMDLINE_PARTITION) += cmdline.o
obj-$(CONFIG_MAC_PARTITION) += mac.o
obj-$(CONFIG_LDM_PARTITION) += ldm.o
obj-$(CONFIG_MSDOS_PARTITION) += msdos.o
diff -puN block/partitions/check.c~block-support-embedded-device-command-line-partition block/partitions/check.c
--- a/block/partitions/check.c~block-support-embedded-device-command-line-partition
+++ a/block/partitions/check.c
@@ -34,6 +34,7 @@
#include "efi.h"
#include "karma.h"
#include "sysv68.h"
+#include "cmdline.h"

int warn_no_part = 1; /*This is ugly: should make genhd removable media aware*/

@@ -65,6 +66,9 @@ static int (*check_part[])(struct parsed
adfspart_check_ADFS,
#endif

+#ifdef CONFIG_CMDLINE_PARTITION
+ cmdline_partition,
+#endif
#ifdef CONFIG_EFI_PARTITION
efi_partition, /* this must come before msdos */
#endif
diff -puN /dev/null block/partitions/cmdline.c
--- /dev/null
+++ a/block/partitions/cmdline.c
@@ -0,0 +1,99 @@
+/*
+ * Copyright (C) 2013 HUAWEI
+ * Author: Cai Zhiyong <[email protected]>
+ *
+ * Read block device partition table from command line.
+ * The partition used for fixed block device (eMMC) embedded device.
+ * It is no MBR, save storage space. Bootloader can be easily accessed
+ * by absolute address of data on the block device.
+ * Users can easily change the partition.
+ *
+ * The format for the command line is just like mtdparts.
+ *
+ * Verbose config please reference "Documentation/block/cmdline-partition.txt"
+ *
+ */
+
+#include <linux/cmdline-parser.h>
+
+#include "check.h"
+#include "cmdline.h"
+
+static char *cmdline;
+static struct cmdline_parts *bdev_parts;
+
+static int add_part(int slot, struct cmdline_subpart *subpart, void *param)
+{
+ int label_min;
+ struct partition_meta_info *info;
+ char tmp[sizeof(info->volname) + 4];
+ struct parsed_partitions *state = (struct parsed_partitions *)param;
+
+ if (slot >= state->limit)
+ return 1;
+
+ put_partition(state, slot, subpart->from >> 9,
+ subpart->size >> 9);
+
+ info = &state->parts[slot].info;
+
+ label_min = min_t(int, sizeof(info->volname) - 1,
+ sizeof(subpart->name));
+ strncpy(info->volname, subpart->name, label_min);
+ info->volname[label_min] = '\0';
+
+ snprintf(tmp, sizeof(tmp), "(%s)", info->volname);
+ strlcat(state->pp_buf, tmp, PAGE_SIZE);
+
+ state->parts[slot].has_info = true;
+
+ return 0;
+}
+
+static int __init cmdline_parts_setup(char *s)
+{
+ cmdline = s;
+ return 1;
+}
+__setup("blkdevparts=", cmdline_parts_setup);
+
+/*
+ * Purpose: allocate cmdline partitions.
+ * Returns:
+ * -1 if unable to read the partition table
+ * 0 if this isn't our partition table
+ * 1 if successful
+ */
+int cmdline_partition(struct parsed_partitions *state)
+{
+ sector_t disk_size;
+ char bdev[BDEVNAME_SIZE];
+ struct cmdline_parts *parts;
+
+ if (cmdline) {
+ if (bdev_parts)
+ cmdline_parts_free(&bdev_parts);
+
+ if (cmdline_parts_parse(&bdev_parts, cmdline)) {
+ cmdline = NULL;
+ return -1;
+ }
+ cmdline = NULL;
+ }
+
+ if (!bdev_parts)
+ return 0;
+
+ bdevname(state->bdev, bdev);
+ parts = cmdline_parts_find(bdev_parts, bdev);
+ if (!parts)
+ return 0;
+
+ disk_size = get_capacity(state->bdev->bd_disk) << 9;
+
+ cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
+
+ strlcat(state->pp_buf, "\n", PAGE_SIZE);
+
+ return 1;
+}
diff -puN /dev/null block/partitions/cmdline.h
--- /dev/null
+++ a/block/partitions/cmdline.h
@@ -0,0 +1,2 @@
+
+int cmdline_partition(struct parsed_partitions *state);
diff -puN block/Kconfig~block-support-embedded-device-command-line-partition block/Kconfig
--- a/block/Kconfig~block-support-embedded-device-command-line-partition
+++ a/block/Kconfig
@@ -99,6 +99,12 @@ config BLK_DEV_THROTTLING

See Documentation/cgroups/blkio-controller.txt for more information.

+config CMDLINE_PARSER
+ bool "Block device command line partition parser"
+ default n
+ ---help---
+ Parsing command line, get the partitions information.
+
menu "Partition Types"

source "block/partitions/Kconfig"
diff -puN block/Makefile~block-support-embedded-device-command-line-partition block/Makefile
--- a/block/Makefile~block-support-embedded-device-command-line-partition
+++ a/block/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched

obj-$(CONFIG_BLOCK_COMPAT) += compat_ioctl.o
obj-$(CONFIG_BLK_DEV_INTEGRITY) += blk-integrity.o
+obj-$(CONFIG_CMDLINE_PARSER) += cmdline-parser.o
diff -puN /dev/null block/cmdline-parser.c
--- /dev/null
+++ a/block/cmdline-parser.c
@@ -0,0 +1,249 @@
+/*
+ * Parse command line, get partition information
+ *
+ * Written by Cai Zhiyong <[email protected]>
+ *
+ */
+#include <linux/buffer_head.h>
+#include <linux/module.h>
+#include <linux/cmdline-parser.h>
+
+static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
+{
+ int ret = 0;
+ struct cmdline_subpart *new_subpart;
+
+ *subpart = NULL;
+
+ new_subpart = kzalloc(sizeof(struct cmdline_subpart), GFP_KERNEL);
+ if (!new_subpart)
+ return -ENOMEM;
+
+ if (*partdef == '-') {
+ new_subpart->size = (sector_t)(~0ULL);
+ partdef++;
+ } else {
+ new_subpart->size = (sector_t)memparse(partdef, &partdef);
+ if (new_subpart->size < (sector_t)PAGE_SIZE) {
+ pr_warn("cmdline partition size is invalid.");
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ if (*partdef == '@') {
+ partdef++;
+ new_subpart->from = (sector_t)memparse(partdef, &partdef);
+ } else {
+ new_subpart->from = (sector_t)(~0ULL);
+ }
+
+ if (*partdef == '(') {
+ int length;
+ char *next = strchr(++partdef, ')');
+
+ if (!next) {
+ pr_warn("cmdline partition format is invalid.");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ length = min_t(int, next - partdef,
+ sizeof(new_subpart->name) - 1);
+ strncpy(new_subpart->name, partdef, length);
+ new_subpart->name[length] = '\0';
+
+ partdef = ++next;
+ } else
+ new_subpart->name[0] = '\0';
+
+ new_subpart->flags = 0;
+
+ if (!strncmp(partdef, "ro", 2)) {
+ new_subpart->flags |= PF_RDONLY;
+ partdef += 2;
+ }
+
+ if (!strncmp(partdef, "lk", 2)) {
+ new_subpart->flags |= PF_POWERUP_LOCK;
+ partdef += 2;
+ }
+
+ *subpart = new_subpart;
+ return 0;
+fail:
+ kfree(new_subpart);
+ return ret;
+}
+
+static void free_subpart(struct cmdline_parts *parts)
+{
+ struct cmdline_subpart *subpart;
+
+ while (parts->subpart) {
+ subpart = parts->subpart;
+ parts->subpart = subpart->next_subpart;
+ kfree(subpart);
+ }
+}
+
+static int parse_parts(struct cmdline_parts **parts, const char *bdevdef)
+{
+ int ret = -EINVAL;
+ char *next;
+ int length;
+ struct cmdline_subpart **next_subpart;
+ struct cmdline_parts *newparts;
+ char buf[BDEVNAME_SIZE + 32 + 4];
+
+ *parts = NULL;
+
+ newparts = kzalloc(sizeof(struct cmdline_parts), GFP_KERNEL);
+ if (!newparts)
+ return -ENOMEM;
+
+ next = strchr(bdevdef, ':');
+ if (!next) {
+ pr_warn("cmdline partition has no block device.");
+ goto fail;
+ }
+
+ length = min_t(int, next - bdevdef, sizeof(newparts->name) - 1);
+ strncpy(newparts->name, bdevdef, length);
+ newparts->name[length] = '\0';
+ newparts->nr_subparts = 0;
+
+ next_subpart = &newparts->subpart;
+
+ while (next && *(++next)) {
+ bdevdef = next;
+ next = strchr(bdevdef, ',');
+
+ length = (!next) ? (sizeof(buf) - 1) :
+ min_t(int, next - bdevdef, sizeof(buf) - 1);
+
+ strncpy(buf, bdevdef, length);
+ buf[length] = '\0';
+
+ ret = parse_subpart(next_subpart, buf);
+ if (ret)
+ goto fail;
+
+ newparts->nr_subparts++;
+ next_subpart = &(*next_subpart)->next_subpart;
+ }
+
+ if (!newparts->subpart) {
+ pr_warn("cmdline partition has no valid partition.");
+ goto fail;
+ }
+
+ *parts = newparts;
+
+ return 0;
+fail:
+ free_subpart(newparts);
+ kfree(newparts);
+ return ret;
+}
+
+void cmdline_parts_free(struct cmdline_parts **parts)
+{
+ struct cmdline_parts *next_parts;
+
+ while (*parts) {
+ next_parts = (*parts)->next_parts;
+ free_subpart(*parts);
+ kfree(*parts);
+ *parts = next_parts;
+ }
+}
+
+int cmdline_parts_parse(struct cmdline_parts **parts, const char *cmdline)
+{
+ int ret;
+ char *buf;
+ char *pbuf;
+ char *next;
+ struct cmdline_parts **next_parts;
+
+ *parts = NULL;
+
+ next = pbuf = buf = kstrdup(cmdline, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ next_parts = parts;
+
+ while (next && *pbuf) {
+ next = strchr(pbuf, ';');
+ if (next)
+ *next = '\0';
+
+ ret = parse_parts(next_parts, pbuf);
+ if (ret)
+ goto fail;
+
+ if (next)
+ pbuf = ++next;
+
+ next_parts = &(*next_parts)->next_parts;
+ }
+
+ if (!*parts) {
+ pr_warn("cmdline partition has no valid partition.");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ ret = 0;
+done:
+ kfree(buf);
+ return ret;
+
+fail:
+ cmdline_parts_free(parts);
+ goto done;
+}
+
+struct cmdline_parts *cmdline_parts_find(struct cmdline_parts *parts,
+ const char *bdev)
+{
+ while (parts && strncmp(bdev, parts->name, sizeof(parts->name)))
+ parts = parts->next_parts;
+ return parts;
+}
+
+/*
+ * add_part()
+ * 0 success.
+ * 1 can not add so many partitions.
+ */
+void cmdline_parts_set(struct cmdline_parts *parts, sector_t disk_size,
+ int slot,
+ int (*add_part)(int, struct cmdline_subpart *, void *),
+ void *param)
+
+{
+ sector_t from = 0;
+ struct cmdline_subpart *subpart;
+
+ for (subpart = parts->subpart; subpart;
+ subpart = subpart->next_subpart, slot++) {
+ if (subpart->from == (sector_t)(~0ULL))
+ subpart->from = from;
+ else
+ from = subpart->from;
+
+ if (from >= disk_size)
+ break;
+
+ if (subpart->size > (disk_size - from))
+ subpart->size = disk_size - from;
+
+ from += subpart->size;
+
+ if (add_part(slot, subpart, param))
+ break;
+ }
+}
diff -puN /dev/null include/linux/cmdline-parser.h
--- /dev/null
+++ a/include/linux/cmdline-parser.h
@@ -0,0 +1,43 @@
+/*
+ * Parsing command line, get the partitions information.
+ *
+ * Written by Cai Zhiyong <[email protected]>
+ *
+ */
+#ifndef CMDLINEPARSEH
+#define CMDLINEPARSEH
+
+#include <linux/blkdev.h>
+
+/* partition flags */
+#define PF_RDONLY 0x01 /* Device is read only */
+#define PF_POWERUP_LOCK 0x02 /* Always locked after reset */
+
+struct cmdline_subpart {
+ char name[BDEVNAME_SIZE]; /* partition name, such as 'rootfs' */
+ sector_t from;
+ sector_t size;
+ int flags;
+ struct cmdline_subpart *next_subpart;
+};
+
+struct cmdline_parts {
+ char name[BDEVNAME_SIZE]; /* block device, such as 'mmcblk0' */
+ unsigned int nr_subparts;
+ struct cmdline_subpart *subpart;
+ struct cmdline_parts *next_parts;
+};
+
+void cmdline_parts_free(struct cmdline_parts **parts);
+
+int cmdline_parts_parse(struct cmdline_parts **parts, const char *cmdline);
+
+struct cmdline_parts *cmdline_parts_find(struct cmdline_parts *parts,
+ const char *bdev);
+
+void cmdline_parts_set(struct cmdline_parts *parts, sector_t disk_size,
+ int slot,
+ int (*add_part)(int, struct cmdline_subpart *, void *),
+ void *param);
+
+#endif /* CMDLINEPARSEH */
_

2013-08-15 03:38:59

[permalink] [raw]

Subject: RE: [PATCH] block: add command line partition parser

> -----Original Message-----
> From: Brian Norris [mailto:[email protected]]
> Sent: Thursday, August 15, 2013 8:12 AM
> To: Andrew Morton
> Cc: Caizhiyong; Karel Zak; [email protected];
> [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani;
> Huang Shijie
> Subject: Re: [PATCH] block: add command line partition parser
>
> On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> <[email protected]> wrote:
> > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:
> >
> >> move the command line parser to a separate module, and change it into
> >> library-style code.
> >>
> >> reference: https://lkml.org/lkml/2013/8/6/550
>
> The most recent patch is an addendum to this linked patch then?
>
> > Well OK. But to prove the library's usefulness and to generally clean
> > up the kernel, someone needs to sign up to the task of converting
> > drivers/mtd/cmdlinepart.c to use this code.
> >
> > I've been hopefully cc'ing various MTD people but am not being
> > overwhelmed with waves of enthusiasm ;)
>
> "I've been" implies that you have done so prior to this email. And
> "people" implies more than one person. I see that you CC'd David
> Woodhouse over a week ago, but he's fairly silent these days on MTD
> things. It's Artem or me who handle most of the day-to-day of MTD. And
> this is the first time I've seen this! (BTW, please include
> [email protected] for anything involving MTD.)
>
> This seems reasonable, and I'd be willing to work with this proposal.
>
> Caizhiyong, can you submit a clear single patch (or series of
> patches), CC'd to linux-mtd at least? Then we can see about supporting
> it in MTD. It doesn't look too difficult, but I need to check that it
> faithfully mimics the capability we currently rely on. There have been
> previous discussions on changing it, but this was rejected in favor of
> allowing more flexibility. Here's part of one such conversation:
>
> http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
>
> So I would recommend:
> (1) consider carefully the implications of your command-line format
> now, rather than later
> (2) if you want MTD to use it, it needs to support the features we use now

It is fully functional reference MTD, :-).

>
> Some particular cases to consider: overlapping partitions (how do
> block devices handle overlapping partitions?), out-of-order
> specification, zero sized partitions, mixed syntax (some specified
> with an offset, some not), multiple '-' partitions.

I think the 'offset' just is used to hide some MTD space.
There are two way:
1) redefine the 'offset' as a gap between forward partition and next partition.
2) add code forbid command line partitions overlapping and out-of-order.

I recommend 1), it seems to solve those problem(overlapping and out-of-order), but it will affect habit.

>
> Anyway, if you resend, we can review.
>
> Thanks,
> Brian

2013-08-15 05:00:23

[permalink] [raw]

Subject: Re: [PATCH] block: add command line partition parser

On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote:
> > -----Original Message-----
> > From: Brian Norris [mailto:[email protected]]
> > Sent: Thursday, August 15, 2013 8:12 AM
> > To: Andrew Morton
> > Cc: Caizhiyong; Karel Zak; [email protected];
> > [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani;
> > Huang Shijie
> > Subject: Re: [PATCH] block: add command line partition parser
> >
> > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> > <[email protected]> wrote:
> > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:
> > >
> > >> move the command line parser to a separate module, and change it into
> > >> library-style code.
> > >>
> > >> reference: https://lkml.org/lkml/2013/8/6/550
> >
> > The most recent patch is an addendum to this linked patch then?
> >
> > > Well OK. But to prove the library's usefulness and to generally clean
> > > up the kernel, someone needs to sign up to the task of converting
> > > drivers/mtd/cmdlinepart.c to use this code.
> > >
> > > I've been hopefully cc'ing various MTD people but am not being
> > > overwhelmed with waves of enthusiasm ;)
> >
> > "I've been" implies that you have done so prior to this email. And
> > "people" implies more than one person. I see that you CC'd David
> > Woodhouse over a week ago, but he's fairly silent these days on MTD
> > things. It's Artem or me who handle most of the day-to-day of MTD. And
> > this is the first time I've seen this! (BTW, please include
> > [email protected] for anything involving MTD.)
> >
> > This seems reasonable, and I'd be willing to work with this proposal.
> >
> > Caizhiyong, can you submit a clear single patch (or series of
> > patches), CC'd to linux-mtd at least? Then we can see about supporting
> > it in MTD. It doesn't look too difficult, but I need to check that it
> > faithfully mimics the capability we currently rely on. There have been
> > previous discussions on changing it, but this was rejected in favor of
> > allowing more flexibility. Here's part of one such conversation:
> >
> > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> > http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
> >
> > So I would recommend:
> > (1) consider carefully the implications of your command-line format
> > now, rather than later
> > (2) if you want MTD to use it, it needs to support the features we use now
>
> It is fully functional reference MTD, :-).

I realize that. I just want to be clear that we have to reconcile (1)
and (2). IOW, if block device requirements stray too far from MTD
requirements, then we might as well drop the idea of integration now.
But if they agree, then we can move forward.

> > Some particular cases to consider: overlapping partitions (how do
> > block devices handle overlapping partitions?), out-of-order
> > specification, zero sized partitions, mixed syntax (some specified
> > with an offset, some not), multiple '-' partitions.
>
> I think the 'offset' just is used to hide some MTD space.

No, it specifies offset as a distance from the beginning of the flash,
so partitions can be numbered out of order. This is intentionally
utilized by some users, for example, to ensure that a particular
partition is always /dev/mtd0, even if it is not the first partition
physically.

> There are two way:
> 1) redefine the 'offset' as a gap between forward partition and next partition.
> 2) add code forbid command line partitions overlapping and out-of-order.
>
> I recommend 1), it seems to solve those problem(overlapping and out-of-order), but it will affect habit.

The linked discussion is where MTD settled on retaining old practice. I
brought it up not so that we change it here, but so that you would
understand what you are agreeing to if you adopt a common MTD and block
device parsing infrastructure.

[Note that I am much less familiar with block device mechanics than with
MTD.] Are any of the problem areas I mentioned actually forbidden on
block devices? I know, for instance, that an MBR partition table can
specify partitions out of order. And I've googled around and seen some
posts about people (unintentionally) ending up with overlapping hard
disk partitions.

So from my primitive knowledge, it sounds like a block devices parser
could agree with the same principle put forward by Shmulik in that
second URL:

"So far, mtdparts commandline parsing has been very lenient and liberal.
I think we should keep this approach; give the user the flexibility,
he'll be responsible to provide meaningful cmdline parts for his
system."

Brian

2013-08-15 06:16:25

[permalink] [raw]

Subject: RE: [PATCH] block: add command line partition parser

> -----Original Message-----
> From: Brian Norris [mailto:[email protected]]
> Sent: Thursday, August 15, 2013 1:00 PM
> To: Caizhiyong
> Cc: Andrew Morton; Karel Zak; [email protected];
> [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani;
> Huang Shijie
> Subject: Re: [PATCH] block: add command line partition parser
>
> On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote:
> > > -----Original Message-----
> > > From: Brian Norris [mailto:[email protected]]
> > > Sent: Thursday, August 15, 2013 8:12 AM
> > > To: Andrew Morton
> > > Cc: Caizhiyong; Karel Zak; [email protected];
> > > [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik
> Ladkani;
> > > Huang Shijie
> > > Subject: Re: [PATCH] block: add command line partition parser
> > >
> > > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> > > <[email protected]> wrote:
> > > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:
> > > >
> > > >> move the command line parser to a separate module, and change it into
> > > >> library-style code.
> > > >>
> > > >> reference: https://lkml.org/lkml/2013/8/6/550
> > >
> > > The most recent patch is an addendum to this linked patch then?
> > >
> > > > Well OK. But to prove the library's usefulness and to generally clean
> > > > up the kernel, someone needs to sign up to the task of converting
> > > > drivers/mtd/cmdlinepart.c to use this code.
> > > >
> > > > I've been hopefully cc'ing various MTD people but am not being
> > > > overwhelmed with waves of enthusiasm ;)
> > >
> > > "I've been" implies that you have done so prior to this email. And
> > > "people" implies more than one person. I see that you CC'd David
> > > Woodhouse over a week ago, but he's fairly silent these days on MTD
> > > things. It's Artem or me who handle most of the day-to-day of MTD. And
> > > this is the first time I've seen this! (BTW, please include
> > > [email protected] for anything involving MTD.)
> > >
> > > This seems reasonable, and I'd be willing to work with this proposal.
> > >
> > > Caizhiyong, can you submit a clear single patch (or series of
> > > patches), CC'd to linux-mtd at least? Then we can see about supporting
> > > it in MTD. It doesn't look too difficult, but I need to check that it
> > > faithfully mimics the capability we currently rely on. There have been
> > > previous discussions on changing it, but this was rejected in favor of
> > > allowing more flexibility. Here's part of one such conversation:
> > >
> > > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> > > http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> > > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
> > >
> > > So I would recommend:
> > > (1) consider carefully the implications of your command-line format
> > > now, rather than later
> > > (2) if you want MTD to use it, it needs to support the features we use now
> >
> > It is fully functional reference MTD, :-).
>
> I realize that. I just want to be clear that we have to reconcile (1)
> and (2). IOW, if block device requirements stray too far from MTD
> requirements, then we might as well drop the idea of integration now.
> But if they agree, then we can move forward.
>
> > > Some particular cases to consider: overlapping partitions (how do
> > > block devices handle overlapping partitions?), out-of-order
> > > specification, zero sized partitions, mixed syntax (some specified
> > > with an offset, some not), multiple '-' partitions.
> >
> > I think the 'offset' just is used to hide some MTD space.
>
> No, it specifies offset as a distance from the beginning of the flash,
> so partitions can be numbered out of order. This is intentionally
> utilized by some users, for example, to ensure that a particular
> partition is always /dev/mtd0, even if it is not the first partition
> physically.
>
> > There are two way:
> > 1) redefine the 'offset' as a gap between forward partition and next partition.
> > 2) add code forbid command line partitions overlapping and out-of-order.
> >
> > I recommend 1), it seems to solve those problem(overlapping and out-of-order),
> but it will affect habit.
>
> The linked discussion is where MTD settled on retaining old practice. I
> brought it up not so that we change it here, but so that you would
> understand what you are agreeing to if you adopt a common MTD and block
> device parsing infrastructure.
>
> [Note that I am much less familiar with block device mechanics than with
> MTD.] Are any of the problem areas I mentioned actually forbidden on
> block devices? I know, for instance, that an MBR partition table can
> specify partitions out of order. And I've googled around and seen some
> posts about people (unintentionally) ending up with overlapping hard
> disk partitions.
>
> So from my primitive knowledge, it sounds like a block devices parser
> could agree with the same principle put forward by Shmulik in that
> second URL:
>
> "So far, mtdparts commandline parsing has been very lenient and liberal.
> I think we should keep this approach; give the user the flexibility,
> he'll be responsible to provide meaningful cmdline parts for his
> system."
>
> Brian

I want to use the MTD command line partition method on block devices (eMMC).
It is very suitable for embedded systems. I think, in embedded system partition method,
if somebody need some feature on MTD device, he may be also need it on block device.
so I fully functional reference MTD command line partition.

I tested the out-of-order and overlapping on my system, used command line partition, It is work ok.
The block device code is not make any restrictions on partition out-of-order and overlapping.

I hope extend the flexibility to block device.

2013-08-15 07:09:44

[permalink] [raw]

Subject: Re: [PATCH] block: add command line partition parser

On Thu, Aug 15, 2013 at 06:16:04AM +0000, Caizhiyong wrote:
> > -----Original Message-----
> > From: Brian Norris [mailto:[email protected]]
> > Sent: Thursday, August 15, 2013 1:00 PM
> > To: Caizhiyong
> > Cc: Andrew Morton; Karel Zak; [email protected];
> > [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani;
> > Huang Shijie
> > Subject: Re: [PATCH] block: add command line partition parser
> >
> > On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote:
> > > > -----Original Message-----
> > > > From: Brian Norris [mailto:[email protected]]
> > > > Sent: Thursday, August 15, 2013 8:12 AM
> > > > To: Andrew Morton
> > > > Cc: Caizhiyong; Karel Zak; [email protected];
> > > > [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik
> > Ladkani;
> > > > Huang Shijie
> > > > Subject: Re: [PATCH] block: add command line partition parser
> > > >
> > > > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> > > > <[email protected]> wrote:
> > > > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]> wrote:
> > > > >
> > > > >> move the command line parser to a separate module, and change it into
> > > > >> library-style code.
> > > > >>
> > > > >> reference: https://lkml.org/lkml/2013/8/6/550
> > > >
> > > > The most recent patch is an addendum to this linked patch then?
> > > >
> > > > > Well OK. But to prove the library's usefulness and to generally clean
> > > > > up the kernel, someone needs to sign up to the task of converting
> > > > > drivers/mtd/cmdlinepart.c to use this code.
> > > > >
> > > > > I've been hopefully cc'ing various MTD people but am not being
> > > > > overwhelmed with waves of enthusiasm ;)
> > > >
> > > > "I've been" implies that you have done so prior to this email. And
> > > > "people" implies more than one person. I see that you CC'd David
> > > > Woodhouse over a week ago, but he's fairly silent these days on MTD
> > > > things. It's Artem or me who handle most of the day-to-day of MTD. And
> > > > this is the first time I've seen this! (BTW, please include
> > > > [email protected] for anything involving MTD.)
> > > >
> > > > This seems reasonable, and I'd be willing to work with this proposal.
> > > >
> > > > Caizhiyong, can you submit a clear single patch (or series of
> > > > patches), CC'd to linux-mtd at least? Then we can see about supporting
> > > > it in MTD. It doesn't look too difficult, but I need to check that it
> > > > faithfully mimics the capability we currently rely on. There have been
> > > > previous discussions on changing it, but this was rejected in favor of
> > > > allowing more flexibility. Here's part of one such conversation:
> > > >
> > > > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> > > > http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> > > > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
> > > >
> > > > So I would recommend:
> > > > (1) consider carefully the implications of your command-line format
> > > > now, rather than later
> > > > (2) if you want MTD to use it, it needs to support the features we use now
> > >
> > > It is fully functional reference MTD, :-).
> >
> > I realize that. I just want to be clear that we have to reconcile (1)
> > and (2). IOW, if block device requirements stray too far from MTD
> > requirements, then we might as well drop the idea of integration now.
> > But if they agree, then we can move forward.
> >
> > > > Some particular cases to consider: overlapping partitions (how do
> > > > block devices handle overlapping partitions?), out-of-order
> > > > specification, zero sized partitions, mixed syntax (some specified
> > > > with an offset, some not), multiple '-' partitions.
> > >
> > > I think the 'offset' just is used to hide some MTD space.
> >
> > No, it specifies offset as a distance from the beginning of the flash,
> > so partitions can be numbered out of order. This is intentionally
> > utilized by some users, for example, to ensure that a particular
> > partition is always /dev/mtd0, even if it is not the first partition
> > physically.
> >
> > > There are two way:
> > > 1) redefine the 'offset' as a gap between forward partition and next partition.
> > > 2) add code forbid command line partitions overlapping and out-of-order.
> > >
> > > I recommend 1), it seems to solve those problem(overlapping and out-of-order),
> > but it will affect habit.
> >
> > The linked discussion is where MTD settled on retaining old practice. I
> > brought it up not so that we change it here, but so that you would
> > understand what you are agreeing to if you adopt a common MTD and block
> > device parsing infrastructure.
> >
> > [Note that I am much less familiar with block device mechanics than with
> > MTD.] Are any of the problem areas I mentioned actually forbidden on
> > block devices? I know, for instance, that an MBR partition table can
> > specify partitions out of order. And I've googled around and seen some
> > posts about people (unintentionally) ending up with overlapping hard
> > disk partitions.
> >
> > So from my primitive knowledge, it sounds like a block devices parser
> > could agree with the same principle put forward by Shmulik in that
> > second URL:
> >
> > "So far, mtdparts commandline parsing has been very lenient and liberal.
> > I think we should keep this approach; give the user the flexibility,
> > he'll be responsible to provide meaningful cmdline parts for his
> > system."
> >
> > Brian
>
> I want to use the MTD command line partition method on block devices (eMMC).
> It is very suitable for embedded systems. I think, in embedded system partition method,
> if somebody need some feature on MTD device, he may be also need it on block device.
> so I fully functional reference MTD command line partition.

I agree.

I'm curious: have you seen any need for a similar arrangement via
device-tree? See, for example, drivers/mtd/ofpart.c.

> I tested the out-of-order and overlapping on my system, used command line partition, It is work ok.
> The block device code is not make any restrictions on partition out-of-order and overlapping.

OK, good. Thanks for checking.

> I hope extend the flexibility to block device.

Sure. I'll try to review the full patch soon and test out integrating
it with MTD.

Thanks,
Brian

2013-08-15 07:47:10

[permalink] [raw]

Subject: RE: [PATCH] block: add command line partition parser

> -----Original Message-----
> From: Brian Norris [mailto:[email protected]]
> Sent: Thursday, August 15, 2013 3:10 PM
> To: Caizhiyong
> Cc: Andrew Morton; Karel Zak; [email protected];
> [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani;
> Huang Shijie
> Subject: Re: [PATCH] block: add command line partition parser
>
> On Thu, Aug 15, 2013 at 06:16:04AM +0000, Caizhiyong wrote:
> > > -----Original Message-----
> > > From: Brian Norris [mailto:[email protected]]
> > > Sent: Thursday, August 15, 2013 1:00 PM
> > > To: Caizhiyong
> > > Cc: Andrew Morton; Karel Zak; [email protected];
> > > [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik
> Ladkani;
> > > Huang Shijie
> > > Subject: Re: [PATCH] block: add command line partition parser
> > >
> > > On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote:
> > > > > -----Original Message-----
> > > > > From: Brian Norris [mailto:[email protected]]
> > > > > Sent: Thursday, August 15, 2013 8:12 AM
> > > > > To: Andrew Morton
> > > > > Cc: Caizhiyong; Karel Zak; [email protected];
> > > > > [email protected]; Wanglin (Albert); Artem Bityutskiy; Shmulik
> > > Ladkani;
> > > > > Huang Shijie
> > > > > Subject: Re: [PATCH] block: add command line partition parser
> > > > >
> > > > > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> > > > > <[email protected]> wrote:
> > > > > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <[email protected]>
> wrote:
> > > > > >
> > > > > >> move the command line parser to a separate module, and change it into
> > > > > >> library-style code.
> > > > > >>
> > > > > >> reference: https://lkml.org/lkml/2013/8/6/550
> > > > >
> > > > > The most recent patch is an addendum to this linked patch then?
> > > > >
> > > > > > Well OK. But to prove the library's usefulness and to generally clean
> > > > > > up the kernel, someone needs to sign up to the task of converting
> > > > > > drivers/mtd/cmdlinepart.c to use this code.
> > > > > >
> > > > > > I've been hopefully cc'ing various MTD people but am not being
> > > > > > overwhelmed with waves of enthusiasm ;)
> > > > >
> > > > > "I've been" implies that you have done so prior to this email. And
> > > > > "people" implies more than one person. I see that you CC'd David
> > > > > Woodhouse over a week ago, but he's fairly silent these days on MTD
> > > > > things. It's Artem or me who handle most of the day-to-day of MTD. And
> > > > > this is the first time I've seen this! (BTW, please include
> > > > > [email protected] for anything involving MTD.)
> > > > >
> > > > > This seems reasonable, and I'd be willing to work with this proposal.
> > > > >
> > > > > Caizhiyong, can you submit a clear single patch (or series of
> > > > > patches), CC'd to linux-mtd at least? Then we can see about supporting
> > > > > it in MTD. It doesn't look too difficult, but I need to check that it
> > > > > faithfully mimics the capability we currently rely on. There have been
> > > > > previous discussions on changing it, but this was rejected in favor of
> > > > > allowing more flexibility. Here's part of one such conversation:
> > > > >
> > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> > > > >
> http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
> > > > >
> > > > > So I would recommend:
> > > > > (1) consider carefully the implications of your command-line format
> > > > > now, rather than later
> > > > > (2) if you want MTD to use it, it needs to support the features we use now
> > > >
> > > > It is fully functional reference MTD, :-).
> > >
> > > I realize that. I just want to be clear that we have to reconcile (1)
> > > and (2). IOW, if block device requirements stray too far from MTD
> > > requirements, then we might as well drop the idea of integration now.
> > > But if they agree, then we can move forward.
> > >
> > > > > Some particular cases to consider: overlapping partitions (how do
> > > > > block devices handle overlapping partitions?), out-of-order
> > > > > specification, zero sized partitions, mixed syntax (some specified
> > > > > with an offset, some not), multiple '-' partitions.
> > > >
> > > > I think the 'offset' just is used to hide some MTD space.
> > >
> > > No, it specifies offset as a distance from the beginning of the flash,
> > > so partitions can be numbered out of order. This is intentionally
> > > utilized by some users, for example, to ensure that a particular
> > > partition is always /dev/mtd0, even if it is not the first partition
> > > physically.
> > >
> > > > There are two way:
> > > > 1) redefine the 'offset' as a gap between forward partition and next partition.
> > > > 2) add code forbid command line partitions overlapping and out-of-order.
> > > >
> > > > I recommend 1), it seems to solve those problem(overlapping and out-of-order),
> > > but it will affect habit.
> > >
> > > The linked discussion is where MTD settled on retaining old practice. I
> > > brought it up not so that we change it here, but so that you would
> > > understand what you are agreeing to if you adopt a common MTD and block
> > > device parsing infrastructure.
> > >
> > > [Note that I am much less familiar with block device mechanics than with
> > > MTD.] Are any of the problem areas I mentioned actually forbidden on
> > > block devices? I know, for instance, that an MBR partition table can
> > > specify partitions out of order. And I've googled around and seen some
> > > posts about people (unintentionally) ending up with overlapping hard
> > > disk partitions.
> > >
> > > So from my primitive knowledge, it sounds like a block devices parser
> > > could agree with the same principle put forward by Shmulik in that
> > > second URL:
> > >
> > > "So far, mtdparts commandline parsing has been very lenient and liberal.
> > > I think we should keep this approach; give the user the flexibility,
> > > he'll be responsible to provide meaningful cmdline parts for his
> > > system."
> > >
> > > Brian
> >
> > I want to use the MTD command line partition method on block devices (eMMC).
> > It is very suitable for embedded systems. I think, in embedded system partition
> method,
> > if somebody need some feature on MTD device, he may be also need it on block device.
> > so I fully functional reference MTD command line partition.
>
> I agree.
>
> I'm curious: have you seen any need for a similar arrangement via
> device-tree? See, for example, drivers/mtd/ofpart.c.

So far, I have no seen. We mainly use ARM. For ARM, device-tree is a new thing.

>
> > I tested the out-of-order and overlapping on my system, used command line partition,
> It is work ok.
> > The block device code is not make any restrictions on partition out-of-order and
> overlapping.
>
> OK, good. Thanks for checking.
>
> > I hope extend the flexibility to block device.
>
> Sure. I'll try to review the full patch soon and test out integrating
> it with MTD.

If there is no problem, I will send my next patch, mtd cmdline parts use cmdline-parser lib.

>
> Thanks,
> Brian

2013-08-15 08:33:00

[permalink] [raw]

Subject: Re: [PATCH] block: add command line partition parser

On 08/15/2013 12:45 AM, Caizhiyong wrote:
>> -----Original Message-----
>> From: Brian Norris [mailto:[email protected]]
...
>> On Thu, Aug 15, 2013 at 06:16:04AM +0000, Caizhiyong wrote:
>>> I want to use the MTD command line partition method on block devices (eMMC).
>>> It is very suitable for embedded systems. I think, in embedded system partition
>> method,
>>> if somebody need some feature on MTD device, he may be also need it on block device.
>>> so I fully functional reference MTD command line partition.
>>
>> I agree.
>>
>> I'm curious: have you seen any need for a similar arrangement via
>> device-tree? See, for example, drivers/mtd/ofpart.c.
>
> So far, I have no seen. We mainly use ARM. For ARM, device-tree is a new thing.

But device-tree is *the* thing for ARM going forward, and the kernel
command line can get unwieldy (and beyond its limits) pretty quickly
like this.

>>> I hope extend the flexibility to block device.
>>
>> Sure. I'll try to review the full patch soon and test out integrating
>> it with MTD.
>
> If there is no problem, I will send my next patch, mtd cmdline parts use cmdline-parser lib.

We will get some reviews on this soon (no time for me tonight). Do you
already have a mtd patch? If so, you might as well post it for review as
well.

Thanks,
Brian

2013-08-15 15:52:15

by Stephen Warren

[permalink] [raw]

Subject: Re: [PATCH] block: support embedded device command line partition

On 08/03/2013 03:57 AM, Caizhiyong wrote:
> From: Cai Zhiyong <[email protected]>
>
> Read block device partition table from command line.
> The partition used for fixed block device (eMMC) embedded device.
> It is no MBR, save storage space. Bootloader can be easily accessed by
> absolute address of data on the block device.
> Users can easily change the partition.
>
> This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
> About the partition verbose reference "Documentation/block/cmdline-partition.txt"

Interesting. NVIDIA Tegra devices running our downstream kernels have a
"tegrapt" (for "Tegra Partition Table") command-line option for
basically the same purpose. While I'd personally prefer we move our eMMC
layout towards standardized GPT, the feature implemented by this patch
may well provide an easy migration/co-existence path instead, so could
be quite useful.

> diff --git a/Documentation/block/cmdline-partition.txt b/Documentation/block/cmdline-partition.txt

> +Read block device partition table from command line.
> +The partition used for fixed block device (eMMC) embedded device.
> +It is no MBR, save storage space. Bootloader can be easily accessed
> +by absolute address of data on the block device.
> +Users can easily change the partition.
> +
> +The format for the command line is just like mtdparts:
> +
> +blkdevparts=<blkdev-def>[;<blkdev-def>]
> + <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
> + <partdef> := <size>[@<offset>](part-name)
> +
> +<blkdev-id>
> + block device disk name, embedded device used fixed block device,
> + it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.

The device-name isn't always fixed.

For example, what if there are multiple SDHCI controllers, one hosting a
fixed eMMC device and the other an SD card? It's quite typical for the
eMMC's device name (which is likely what should be affected by this
feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
an SD card is present. Is there a more precise/stable way to define
which device the command-line option applies to?

For the root= command-line option, we use UUID= or PARTUUID= to work
around this issue, but that won't work for naming the whole device.

What about using the MMIO address of the controller hosting the device,
or something like that?

> +<size>
> + partition size, in bytes, such as: 512, 1m, 1G.

s/m/M/?

I assume M/G are MiB/GiB?

Does it make sense to allow specifying the sizes in units of
sectors/blocks? If so, which specific block/sector size in the case of
things like NAND flash which IIRC have multiple types/levels of sectors;
perhaps this is a bad idea. I guess we could easily add this feature
later by introducing a new suffix, so no need to solve the issue now.

> +
> +<offset>
> + partition start address, in bytes.
> +
> +(part-name)
> + partition name, kernel send uevent with "PARTNAME". application can create
> + a link to block device partition with the name "PARTNAME".
> + user space application can access partition by partition name.

Do partitions usually have a PARTNAME attribute when probed through
normal mechanisms like MBR? If so, I guess this is fine.

Perhaps we can just use , as the delimiter for all fields, rather than
special-casing part-name to use (), so:

size,offset,partname,size,offset,partname,...

The partname field could easily be empty if not needed.

> +Example:
> + eMMC disk name is "mmcblk0" and "mmcblk0boot0"
> +
> + bootargs:
> + 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
> +
> + dmesg:
> + mmcblk0: p1(data0) p2(data1) p3()
> + mmcblk0boot0: p1(boot) p2(kernel)

2013-08-16 02:54:42

[permalink] [raw]

Subject: RE: [PATCH] block: support embedded device command line partition

> > +blkdevparts=<blkdev-def>[;<blkdev-def>]
> > + <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
> > + <partdef> := <size>[@<offset>](part-name)
> > +
> > +<blkdev-id>
> > + block device disk name, embedded device used fixed block device,
> > + it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
>
> The device-name isn't always fixed.
>
> For example, what if there are multiple SDHCI controllers, one hosting a
> fixed eMMC device and the other an SD card? It's quite typical for the
> eMMC's device name (which is likely what should be affected by this
> feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
> an SD card is present. Is there a more precise/stable way to define
> which device the command-line option applies to?

Yes. Fixed is for single controller.
For multiple controllers, currently, there is not a simple way.
I tend to do something in the eMMC driver, such as initialize order,
but I have not tried.

>
> For the root= command-line option, we use UUID= or PARTUUID= to work
> around this issue, but that won't work for naming the whole device.
>
> What about using the MMIO address of the controller hosting the device,
> or something like that?
>

MMIO may be not a good idea, it is not intuitive.

> > +<size>
> > + partition size, in bytes, such as: 512, 1m, 1G.
>
> s/m/M/?
>
> I assume M/G are MiB/GiB?
>
> Does it make sense to allow specifying the sizes in units of
> sectors/blocks? If so, which specific block/sector size in the case of
> things like NAND flash which IIRC have multiple types/levels of sectors;
> perhaps this is a bad idea. I guess we could easily add this feature
> later by introducing a new suffix, so no need to solve the issue now.
>
> > +
> > +<offset>
> > + partition start address, in bytes.
> > +
> > +(part-name)
> > + partition name, kernel send uevent with "PARTNAME". application can create
> > + a link to block device partition with the name "PARTNAME".
> > + user space application can access partition by partition name.
>
> Do partitions usually have a PARTNAME attribute when probed through
> normal mechanisms like MBR? If so, I guess this is fine.
>
> Perhaps we can just use , as the delimiter for all fields, rather than
> special-casing part-name to use (), so:
>
> size,offset,partname,size,offset,partname,...
>
> The partname field could easily be empty if not needed.
>

If no need partname, your bootargs are mmcblk0:1G,1G,1G,...

> > +Example:
> > + eMMC disk name is "mmcblk0" and "mmcblk0boot0"
> > +
> > + bootargs:
> > +
> 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
> > +
> > + dmesg:
> > + mmcblk0: p1(data0) p2(data1) p3()
> > + mmcblk0boot0: p1(boot) p2(kernel)

2013-08-16 16:02:47

by Stephen Warren

[permalink] [raw]

Subject: Re: [PATCH] block: support embedded device command line partition

On 08/15/2013 08:54 PM, Caizhiyong wrote:
>>> +blkdevparts=<blkdev-def>[;<blkdev-def>]
>>> + <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
>>> + <partdef> := <size>[@<offset>](part-name)
>>> +
>>> +<blkdev-id>
>>> + block device disk name, embedded device used fixed block device,
>>> + it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
>>
>> The device-name isn't always fixed.
>>
>> For example, what if there are multiple SDHCI controllers, one hosting a
>> fixed eMMC device and the other an SD card? It's quite typical for the
>> eMMC's device name (which is likely what should be affected by this
>> feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
>> an SD card is present. Is there a more precise/stable way to define
>> which device the command-line option applies to?
>
> Yes. Fixed is for single controller.
> For multiple controllers, currently, there is not a simple way.
> I tend to do something in the eMMC driver, such as initialize order,
> but I have not tried.

There have been proposals before to try and create a fixed naming for
the controllers (or rather the block devices they generate...) but
they've been rejected. I don't think we should rely on being able to do
that.

>>> +
>>> +<offset>
>>> + partition start address, in bytes.
>>> +
>>> +(part-name)
>>> + partition name, kernel send uevent with "PARTNAME". application can create
>>> + a link to block device partition with the name "PARTNAME".
>>> + user space application can access partition by partition name.
>>
>> Do partitions usually have a PARTNAME attribute when probed through
>> normal mechanisms like MBR? If so, I guess this is fine.
>>
>> Perhaps we can just use , as the delimiter for all fields, rather than
>> special-casing part-name to use (), so:
>>
>> size,offset,partname,size,offset,partname,...
>>
>> The partname field could easily be empty if not needed.
>
> If no need partname, your bootargs are mmcblk0:1G,1G,1G,...

Well, you always need the offset too. I don't think there's any harm in
forcing all fields to be specified in all cases; it makes the whole
system much more regular and less error-prone.

Alternatively, use a different separator between fields for a given
partition, and between partitions, e.g.:

size,offset,partname;size,offset,partname

That way, you know that if you see a ; you're looking at a new
partition, and hence the partname field need not always be specified.
Although, if you want to specify a partname but not an offset you'd
still need empty fields, so just requiring all fields to always be
present still seems safest to me.

2013-08-19 08:37:13

[permalink] [raw]

Subject: RE: [PATCH] block: support embedded device command line partition

> On 08/15/2013 08:54 PM, Caizhiyong wrote:
> >>> +blkdevparts=<blkdev-def>[;<blkdev-def>]
> >>> + <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
> >>> + <partdef> := <size>[@<offset>](part-name)
> >>> +
> >>> +<blkdev-id>
> >>> + block device disk name, embedded device used fixed block device,
> >>> + it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
> >>
> >> The device-name isn't always fixed.
> >>
> >> For example, what if there are multiple SDHCI controllers, one hosting a
> >> fixed eMMC device and the other an SD card? It's quite typical for the
> >> eMMC's device name (which is likely what should be affected by this
> >> feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
> >> an SD card is present. Is there a more precise/stable way to define
> >> which device the command-line option applies to?
> >
> > Yes. Fixed is for single controller.
> > For multiple controllers, currently, there is not a simple way.
> > I tend to do something in the eMMC driver, such as initialize order,
> > but I have not tried.
>
> There have been proposals before to try and create a fixed naming for
> the controllers (or rather the block devices they generate...) but
> they've been rejected. I don't think we should rely on being able to do
> that.
>
> >>> +
> >>> +<offset>
> >>> + partition start address, in bytes.
> >>> +
> >>> +(part-name)
> >>> + partition name, kernel send uevent with "PARTNAME". application can create
> >>> + a link to block device partition with the name "PARTNAME".
> >>> + user space application can access partition by partition name.
> >>
> >> Do partitions usually have a PARTNAME attribute when probed through
> >> normal mechanisms like MBR? If so, I guess this is fine.
> >>
> >> Perhaps we can just use , as the delimiter for all fields, rather than
> >> special-casing part-name to use (), so:
> >>
> >> size,offset,partname,size,offset,partname,...
> >>
> >> The partname field could easily be empty if not needed.
> >
> > If no need partname, your bootargs are mmcblk0:1G,1G,1G,...
>
> Well, you always need the offset too. I don't think there's any harm in
> forcing all fields to be specified in all cases; it makes the whole
> system much more regular and less error-prone.
>
> Alternatively, use a different separator between fields for a given
> partition, and between partitions, e.g.:
>
> size,offset,partname;size,offset,partname
>
> That way, you know that if you see a ; you're looking at a new
> partition, and hence the partname field need not always be specified.
> Although, if you want to specify a partname but not an offset you'd
> still need empty fields, so just requiring all fields to always be
> present still seems safest to me.

I just follow MTD cmdline partition format.(reference drivers/mtd/cmdlinepart.c)
There are many pitfalls in using this partition format, the designer is more
consideration its ease of use, rather than safe.
There is an other conversation: https://lkml.org/lkml/2013/8/3/16

2013-08-19 16:05:32

by Stephen Warren

[permalink] [raw]

Subject: Re: [PATCH] block: support embedded device command line partition

On 08/19/2013 02:36 AM, Caizhiyong wrote:
>> On 08/15/2013 08:54 PM, Caizhiyong wrote:
>>>>> +blkdevparts=<blkdev-def>[;<blkdev-def>]
>>>>> + <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
>>>>> + <partdef> := <size>[@<offset>](part-name)
>>>>> +
>>>>> +<blkdev-id>
>>>>> + block device disk name, embedded device used fixed block device,
>>>>> + it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
>>>>
>>>> The device-name isn't always fixed.
>>>>
>>>> For example, what if there are multiple SDHCI controllers, one hosting a
>>>> fixed eMMC device and the other an SD card? It's quite typical for the
>>>> eMMC's device name (which is likely what should be affected by this
>>>> feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
>>>> an SD card is present. Is there a more precise/stable way to define
>>>> which device the command-line option applies to?
>>>
>>> Yes. Fixed is for single controller.
>>> For multiple controllers, currently, there is not a simple way.
>>> I tend to do something in the eMMC driver, such as initialize order,
>>> but I have not tried.
>>
>> There have been proposals before to try and create a fixed naming for
>> the controllers (or rather the block devices they generate...) but
>> they've been rejected. I don't think we should rely on being able to do
>> that.
>>
>>>>> +
>>>>> +<offset>
>>>>> + partition start address, in bytes.
>>>>> +
>>>>> +(part-name)
>>>>> + partition name, kernel send uevent with "PARTNAME". application can create
>>>>> + a link to block device partition with the name "PARTNAME".
>>>>> + user space application can access partition by partition name.
>>>>
>>>> Do partitions usually have a PARTNAME attribute when probed through
>>>> normal mechanisms like MBR? If so, I guess this is fine.
>>>>
>>>> Perhaps we can just use , as the delimiter for all fields, rather than
>>>> special-casing part-name to use (), so:
>>>>
>>>> size,offset,partname,size,offset,partname,...
>>>>
>>>> The partname field could easily be empty if not needed.
>>>
>>> If no need partname, your bootargs are mmcblk0:1G,1G,1G,...
>>
>> Well, you always need the offset too. I don't think there's any harm in
>> forcing all fields to be specified in all cases; it makes the whole
>> system much more regular and less error-prone.
>>
>> Alternatively, use a different separator between fields for a given
>> partition, and between partitions, e.g.:
>>
>> size,offset,partname;size,offset,partname
>>
>> That way, you know that if you see a ; you're looking at a new
>> partition, and hence the partname field need not always be specified.
>> Although, if you want to specify a partname but not an offset you'd
>> still need empty fields, so just requiring all fields to always be
>> present still seems safest to me.
>
> I just follow MTD cmdline partition format.(reference drivers/mtd/cmdlinepart.c)

Ah OK, consistency with an existing format used for similar purposes
probably does override any other concerns.

> There are many pitfalls in using this partition format, the designer is more
> consideration its ease of use, rather than safe.
> There is an other conversation: https://lkml.org/lkml/2013/8/3/16

2013-09-17 11:15:50

by Linus Walleij

[permalink] [raw]

Subject: Re: [PATCH] block: support embedded device command line partition

On Sat, Aug 3, 2013 at 11:57 AM, Caizhiyong <[email protected]> wrote:

> From: Cai Zhiyong <[email protected]>
>
> Read block device partition table from command line.
> The partition used for fixed block device (eMMC) embedded device.
> It is no MBR, save storage space. Bootloader can be easily accessed by
> absolute address of data on the block device.
> Users can easily change the partition.
>
> This code reference MTD partition, source "drivers/mtd/cmdlinepart.c"
> About the partition verbose reference "Documentation/block/cmdline-partition.txt"
>
> Signed-off-by: Cai Zhiyong <[email protected]>

I saw this patch appear in kernel v3.12-rc1, and it's nice since it's exactly
what we need. So needed that we proposed it in 2010:
http://marc.info/?l=linux-kernel&m=127425650923757&w=2
http://marc.info/?l=linux-kernel&m=127599718024364&w=2

Is this patch inspired by Ulfs patch? (I can see the code is different,
but the cmdline argument is the same for example.) Some credit
could have been proper in that case.

Just asking: sometimes wheels do get reinvented.

Yours,
Linus Walleij

2013-09-17 13:08:40