All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.