On Wed, 2012-08-29 at 11:51 +0300, Shmulik Ladkani wrote:
> > While you suggestion is clever, do we really benefit from this?
>
> Artem, please note this is just a side effect of what I've suggested
> (that its, continue parsing after first truncated partition), not a real
> use case I'd expect an
On Wed, 29 Aug 2012 11:16:05 +0300 Artem Bityutskiy wrote:
> On Sun, 2012-08-26 at 09:06 +0300, Shmulik Ladkani wrote:
> > root100m@0
> > kernel 100m@100m
> > rootfs 800m@200m (truncated)
> > user0@1g (truncated)
> > rest0@1g
>
> Who would benefit from having tho
于 2012年08月29日 16:24, Artem Bityutskiy 写道:
While appreciating Shmulik's attention to details, I vote this way:
On Sun, 2012-08-26 at 02:47 -0400, Huang Shijie wrote:
Could Artem or David point us a direction about this?
[1] Should the unsorted partitions be supported?
No, it is asking for trou
While appreciating Shmulik's attention to details, I vote this way:
On Sun, 2012-08-26 at 02:47 -0400, Huang Shijie wrote:
> Could Artem or David point us a direction about this?
> [1] Should the unsorted partitions be supported?
No, it is asking for troubles.
> [2] And what should we do when w
On Sun, 2012-08-26 at 09:06 +0300, Shmulik Ladkani wrote:
> root 100m@0
> kernel100m@100m
> rootfs800m@200m (truncated)
> user 0@1g (truncated)
> rest 0@1g
Who would benefit from having those 2 0-sized partitions and how? How
many users/scripts would be confused by this (these 2
On Sun, Aug 26, 2012 at 2:06 AM, Shmulik Ladkani
wrote:
> Hi,
>
> On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie wrote:
>> On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani
>> wrote:
>> > Your analysis seems right, but let me offer an alternative approach.
>> >
>> > I would simply:
>> >
>> > -
Hi,
On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie wrote:
> On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani
> wrote:
> > Your analysis seems right, but let me offer an alternative approach.
> >
> > I would simply:
> >
> > - part->num_parts = i;
> your code
On Sat, Aug 25, 2012 at 5:42 AM, Shmulik Ladkani
wrote:
> On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie wrote:
>> > 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 be
On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie wrote:
> > 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 trunc
On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani
wrote:
> Hi Huang,
>
> On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie 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
Hi Huang,
On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie 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(struc
Assume we have a 1GB(8Gb) nand chip, and we set the partitions
in the command line like this:
#gpmi-nand:100m(boot),100m(kernel),1g(rootfs)
In this case, the partition truncating occurs. The current code will
get the following result:
--
root@frees
12 matches
Mail list logo
