All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, Huang Shijie <shijie8@gmail.com>
Subject: Re: [PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict
Date: Tue, 4 Sep 2012 14:48:26 +0300	[thread overview]
Message-ID: <20120904144826.7b9b7518@halley> (raw)
In-Reply-To: <1346686544.3061.75.camel@sauron.fi.intel.com>

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.
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

  parent reply	other threads:[~2012-09-04 11:48 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 [this message]
2012-09-05  2:12         ` Huang Shijie
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=20120904144826.7b9b7518@halley \
    --to=shmulik.ladkani@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=shijie8@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.