Re: [PATCH] block: add command line partition parser

[Brian Norris]

On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote:
> > -----Original Message-----
> > From: Brian Norris [mailto:computersforpeace@xxxxxxxxx]
> > Sent: Thursday, August 15, 2013 8:12 AM
> > To: Andrew Morton
> > Cc: Caizhiyong; Karel Zak; linux-mtd@xxxxxxxxxxxxxxxxxxx;
> > linux-kernel@xxxxxxxxxxxxxxx; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani;
> > Huang Shijie
> > Subject: Re: [PATCH] block: add command line partition parser
> > 
> > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <caizhiyong@xxxxxxxxxx> wrote:
> > >
> > >> move the command line parser to a separate module, and change it into
> > >> library-style code.
> > >>
> > >> reference: https://lkml.org/lkml/2013/8/6/550
> > 
> > The most recent patch is an addendum to this linked patch then?
> > 
> > > Well OK.  But to prove the library's usefulness and to generally clean
> > > up the kernel, someone needs to sign up to the task of converting
> > > drivers/mtd/cmdlinepart.c to use this code.
> > >
> > > I've been hopefully cc'ing various MTD people but am not being
> > > overwhelmed with waves of enthusiasm ;)
> > 
> > "I've been" implies that you have done so prior to this email. And
> > "people" implies more than one person. I see that you CC'd David
> > Woodhouse over a week ago, but he's fairly silent these days on MTD
> > things. It's Artem or me who handle most of the day-to-day of MTD. And
> > this is the first time I've seen this! (BTW, please include
> > linux-mtd@xxxxxxxxxxxxxxxxxxx for anything involving MTD.)
> > 
> > This seems reasonable, and I'd be willing to work with this proposal.
> > 
> > Caizhiyong, can you submit a clear single patch (or series of
> > patches), CC'd to linux-mtd at least? Then we can see about supporting
> > it in MTD. It doesn't look too difficult, but I need to check that it
> > faithfully mimics the capability we currently rely on. There have been
> > previous discussions on changing it, but this was rejected in favor of
> > allowing more flexibility. Here's part of one such conversation:
> > 
> > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html
> > http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html
> > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html
> > 
> > So I would recommend:
> > (1) consider carefully the implications of your command-line format
> > now, rather than later
> > (2) if you want MTD to use it, it needs to support the features we use now
> 
> It is fully functional reference MTD, :-).

I realize that. I just want to be clear that we have to reconcile (1)
and (2). IOW, if block device requirements stray too far from MTD
requirements, then we might as well drop the idea of integration now.
But if they agree, then we can move forward.

> > Some particular cases to consider: overlapping partitions (how do
> > block devices handle overlapping partitions?), out-of-order
> > specification, zero sized partitions, mixed syntax (some specified
> > with an offset, some not), multiple '-' partitions.
> 
> I think the 'offset' just is used to hide some MTD space.

No, it specifies offset as a distance from the beginning of the flash,
so partitions can be numbered out of order. This is intentionally
utilized by some users, for example, to ensure that a particular
partition is always /dev/mtd0, even if it is not the first partition
physically.

> There are two way:
> 1) redefine the 'offset' as a gap between forward partition and next partition.
> 2) add code forbid command line partitions overlapping and out-of-order.
> 
> I recommend 1), it seems to solve those problem(overlapping and out-of-order), but it will affect habit.

The linked discussion is where MTD settled on retaining old practice. I
brought it up not so that we change it here, but so that you would
understand what you are agreeing to if you adopt a common MTD and block
device parsing infrastructure.

[Note that I am much less familiar with block device mechanics than with
MTD.] Are any of the problem areas I mentioned actually forbidden on
block devices? I know, for instance, that an MBR partition table can
specify partitions out of order. And I've googled around and seen some
posts about people (unintentionally) ending up with overlapping hard
disk partitions.

So from my primitive knowledge, it sounds like a block devices parser
could agree with the same principle put forward by Shmulik in that
second URL:

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

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/