From: Huang Shijie <b32955@freescale.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: Huang Shijie <shijie8@gmail.com>,
linux-mtd@lists.infradead.org, dedekind1@gmail.com
Subject: Re: [PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict
Date: Wed, 5 Sep 2012 10:12:20 +0800 [thread overview]
Message-ID: <5046B504.6000608@freescale.com> (raw)
In-Reply-To: <20120904144826.7b9b7518@halley>
于 2012年09月04日 19:48, Shmulik Ladkani 写道:
> On Mon, 03 Sep 2012 18:35:44 +0300 Artem Bityutskiy<dedekind1@gmail.com> wrote:
>> With the logic I suggested, for this case what I said would basically:
>>
>> 1. Sort. This leads to
>>
>> 100m@100m(kernel)
>> 1g@200m(rootfs)
>> 100m(boot)
>>
>> "OFFSET_CONTINOUS" is always the largest and will be at the end when
>> sorting.
>>
>> 2. Verification.
>>
>> We verify for overlaps and gaps. And refuse this one.
> Artem, Huang,
>
> Sorry for the long delay, got busy with urgent matters (found out I need
> to go thru some surgery), I will probably not be available in the
> upcoming days, but I've read the correspondance and wanted to share my
> two cents...
>
> My POV is that sorting and verification is not needed, is troublesome,
> and might affect users in ways they don't expect.
>
> 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.
>
> Actually, Huang's initial complaint was that 'parse_cmdline_partitions'
> was too strict - the truncated partition was not registered!
>
> Now, philosophy aside, let's talk about some usecases that might break.
>
> I remember overlapping partitions (more precisely, partition that is a
> subset of another) being common in some embedded systems, where the
> "rootfs" and "kernel" partitions are a subset of the "overall image"
> partition.
> Why break this? if users enjoy the flexibility, and careful not to
> create silly partitions, I'm in favor of keeping the flexibility.
>
> Same goes for sorting.
> If one has a system hacked to work with mtd0 hardcodedly, but mtd0's
> physical location is somewhere at the end of the device, why reorder the
> partitions enumeration affecting this system?
>
> I'd say keep it simple and flexible.
yes, it's really simple and flexible.
But I think it's not wise to export the 0-size partition to user.
The user may confused at this.
And the mtd-utils, such as mtd-info/mtd-debug, do they can work with a
0-size partition?
thanks
Huang Shijie
> I trust the user to provide meaningful partitions in the cmdline.
>
> Anyways, please consider this approach.
>
> My patch suggestion might look as (and might need some rework):
>
> diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
> index 17b0bd4..f5df613 100644
> --- a/drivers/mtd/cmdlinepart.c
> +++ b/drivers/mtd/cmdlinepart.c
> @@ -324,7 +324,6 @@ static int parse_cmdline_partitions(struct mtd_info *master,
> "%s: partitioning exceeds flash size, truncating\n",
> part->mtd_id);
> part->parts[i].size = master->size - offset;
> - part->num_parts = i;
> }
> offset += part->parts[i].size;
> }
>
> Regards,
> Shmulik
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
next prev parent reply other threads:[~2012-09-05 2:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-26 17:21 [PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict Huang Shijie
2012-08-26 17:21 ` Huang Shijie
2012-08-26 17:21 ` [PATCH 2/3] mtd: cmdlinepart: sort the unsorted partitions Huang Shijie
2012-08-26 17:21 ` Huang Shijie
2012-08-31 13:59 ` Artem Bityutskiy
2012-08-31 13:59 ` Artem Bityutskiy
2012-08-31 14:29 ` Huang Shijie
2012-08-31 14:29 ` Huang Shijie
2012-09-03 7:21 ` Artem Bityutskiy
2012-09-03 7:21 ` Artem Bityutskiy
2012-08-26 17:21 ` [PATCH 3/3] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs Huang Shijie
2012-08-26 17:21 ` Huang Shijie
2012-08-30 6:43 ` Artem Bityutskiy
2012-08-30 6:43 ` Artem Bityutskiy
2012-08-30 6:39 ` Huang Shijie
2012-08-30 6:39 ` Huang Shijie
2012-08-31 11:45 ` [PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict Artem Bityutskiy
2012-08-31 11:45 ` Artem Bityutskiy
2012-08-31 13:36 ` Huang Shijie
2012-08-31 13:36 ` Huang Shijie
2012-08-31 14:30 ` Huang Shijie
2012-08-31 14:30 ` Huang Shijie
2012-09-03 7:18 ` Artem Bityutskiy
2012-09-03 7:18 ` Artem Bityutskiy
2012-09-03 15:09 ` Huang Shijie
2012-09-03 15:09 ` Huang Shijie
2012-09-03 15:35 ` Artem Bityutskiy
2012-09-04 3:23 ` Huang Shijie
2012-09-04 11:48 ` Shmulik Ladkani
2012-09-05 2:12 ` Huang Shijie [this message]
2012-09-05 5:30 ` Shmulik Ladkani
2012-09-22 16:01 ` Artem Bityutskiy
2012-12-17 1:11 ` Christopher Cordahi
2012-12-18 5:27 ` Brian Norris
2013-01-15 11:49 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5046B504.6000608@freescale.com \
--to=b32955@freescale.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=shijie8@gmail.com \
--cc=shmulik.ladkani@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.