From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Huang Shijie <shijie8@gmail.com>
Cc: linux-mtd@lists.infradead.org, dwmw2@infradead.org,
linux-kernel@vger.kernel.org, dedekind1@gmail.com
Subject: Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs
Date: Sat, 25 Aug 2012 12:02:31 +0300 [thread overview]
Message-ID: <20120825120231.73577d6a@halley> (raw)
In-Reply-To: <1345904767-23011-1-git-send-email-shijie8@gmail.com>
Hi Huang,
On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie <shijie8@gmail.com> wrote:
> diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
> index 4558e0f..fc960a3 100644
> --- a/drivers/mtd/cmdlinepart.c
> +++ b/drivers/mtd/cmdlinepart.c
> @@ -344,7 +344,8 @@ 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;
> + part->num_parts = i + 1;
> + break;
Your analysis seems right, but let me offer an alternative approach.
I would simply:
- part->num_parts = i;
(and not replace it with anything).
The specified cmdline partitions might not be ordered (according to
start offset), so next partition specified after the truncated one might
define a partition at the beginning of the device, which is okay
(regardless the truncation of current partition).
Your patch skips the definitions of next partitions, which can be legit.
I agree specifying "unsorted" partitions is not commonly used (and it
might make no sense when using the "remaining" syntax), but it is legit
to define all partitions _explicitly_ with their size@offset in an
unordered fashion.
Regards,
Shmulik
WARNING: multiple messages have this Message-ID (diff)
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Huang Shijie <shijie8@gmail.com>
Cc: dwmw2@infradead.org, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org, dedekind1@gmail.com
Subject: Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs
Date: Sat, 25 Aug 2012 12:02:31 +0300 [thread overview]
Message-ID: <20120825120231.73577d6a@halley> (raw)
In-Reply-To: <1345904767-23011-1-git-send-email-shijie8@gmail.com>
Hi Huang,
On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie <shijie8@gmail.com> wrote:
> diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
> index 4558e0f..fc960a3 100644
> --- a/drivers/mtd/cmdlinepart.c
> +++ b/drivers/mtd/cmdlinepart.c
> @@ -344,7 +344,8 @@ 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;
> + part->num_parts = i + 1;
> + break;
Your analysis seems right, but let me offer an alternative approach.
I would simply:
- part->num_parts = i;
(and not replace it with anything).
The specified cmdline partitions might not be ordered (according to
start offset), so next partition specified after the truncated one might
define a partition at the beginning of the device, which is okay
(regardless the truncation of current partition).
Your patch skips the definitions of next partitions, which can be legit.
I agree specifying "unsorted" partitions is not commonly used (and it
might make no sense when using the "remaining" syntax), but it is legit
to define all partitions _explicitly_ with their size@offset in an
unordered fashion.
Regards,
Shmulik
next prev parent reply other threads:[~2012-08-25 8:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-25 14:26 [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs Huang Shijie
2012-08-25 14:26 ` Huang Shijie
2012-08-25 9:02 ` Shmulik Ladkani [this message]
2012-08-25 9:02 ` Shmulik Ladkani
2012-08-25 9:26 ` Huang Shijie
2012-08-25 9:26 ` Huang Shijie
2012-08-25 9:42 ` Shmulik Ladkani
2012-08-25 9:42 ` Shmulik Ladkani
2012-08-25 11:07 ` Huang Shijie
2012-08-25 11:07 ` Huang Shijie
2012-08-26 6:06 ` Shmulik Ladkani
2012-08-26 6:06 ` Shmulik Ladkani
2012-08-26 6:47 ` Huang Shijie
2012-08-26 6:47 ` Huang Shijie
2012-08-29 8:24 ` Artem Bityutskiy
2012-08-29 8:24 ` Artem Bityutskiy
2012-08-29 8:48 ` Huang Shijie
2012-08-29 8:48 ` Huang Shijie
2012-08-29 8:16 ` Artem Bityutskiy
2012-08-29 8:16 ` Artem Bityutskiy
2012-08-29 8:51 ` Shmulik Ladkani
2012-08-29 8:51 ` Shmulik Ladkani
2012-08-29 9:10 ` Artem Bityutskiy
2012-08-29 9:10 ` 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=20120825120231.73577d6a@halley \
--to=shmulik.ladkani@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--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.