[PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict

[Christopher Cordahi]

Huang Shijie <b32955 <at> freescale.com> writes:

> 于 2012年09月04日 19:48, Shmulik Ladkani 写道:
> >
> > 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.

Is it agreed that sorting is not necessary and will not be implemented?
If so are there objections to me modifying the documentation to indicate
that out of order partitions is part of the supported design?

In my embedded distribution, I would like to introduce a MTD partition
at the end of the list to not affect existing hardcoded MTD numbers.

The fw_printenv/fw_setenv command line interface to U-Boot environment
makes use of a /etc/fw_env.config with hardcoded device numbers which
would be broken by a sort.

Although my out of order partitions worked, I couldn't find any
documentation indicating it was a supported feature.  This thread with
Artem's support for sorting got me worried.

If the only reason for sorting is to prevent overlapping partitions,
I think this can be written just as efficiently without a sort although
Shmulik also gives a reason why this restriction should not exist.
I'd prefer to accept that task rather than have to handle changing
MTD numbers.

> But I think it's not wise to export the 0-size partition to user.
> The user may confused at this.

Although I just submitted a patch to improve this, personally I think
if a user specifies a zero sized partition, they should get it.  Or if
it's inherently incorrect I think it should be an error.  Similarly
I'd expect the same for truncated partitions, either provide the size
specified or error.  Since I don't ever foresee using either of these
two features I don't have any objections to current situation.  These
are just my $0.02

--
Chris