Re: [PATCH v2] init: add root=PARTUUID=UUID,PARTNROFF=%d support

[Will Drewry]

On Sun, Jun 26, 2011 at 11:43 AM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> On Fri, Jun 24, 2011 at 21:53, Will Drewry <wad@xxxxxxxxxxxx> wrote:
>
>> Upon further inspection, the code changes would not directly break any
>> existing code, but PARTUUID=...,PARTNROFF= would not be usable via the
>> other entrypoints to name_to_dev_t.  E.g., block2mtd or md because
>> they take in comma-separated parameters prior to calling
>> name_to_dev_t.  That seems like it'd be less than ideal.
>>
>> Kay,  Do you have a strong preference around the ,PARTNROFF= syntax?
>> I'm not sure what the cleanest approach is, but I'm inclined to finish
>> other patch cleanup (and documentation) and repost with '/' as the
>> separator instead of ','.   At present ',' is reused across several
>> places where devices are supplied by "name", but '/' is expected as
>> part of the normal path semantic.  The other option would be to use
>> ':' instead. ':' isn't usually overloaded as it is expected as part of
>> a the device major:minor naming scheme, but slashes seem more sane
>> even if weird:
>>
>>  PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF/PARTNROFF=1
>>
>> I'll repost along these lines unless someone indicates that this is
>> too grotesque to consider.
>
> Hmm, '/' might look a bit strange in the context of a path, which is
> the common use case for root=.

Yeah - that was why I was considering colons too, but slashes seemed
less likely to have other weird expectations.

> We catch PARTUUID before parsing any of the other options, right? So
> we can't really break anything.

For root= parsing, it's always okay.  The problem is if you want to
use PARTUUID=...,PARTNR=.. as a device "name" in an argument to md= or
to mtd2block.  Both of those take their device name from a
comma-separated argument list.  While they could be fixed up to
support this syntax, it seems that it would make things pretty
confusing.  (The other option is to just not support this naming
scheme via those input paths.)

> Fstab and mount options in general all use ',' to separate keywords,
> and I think we should do the same here. I think the ',' still looks
> more natural than an artificial '/' to avoid possibly breaking
> something we don't even call into. :)

I think the comma looks better too, but I wasn't sure if it'd be fair
game to provide a early-init device resolution path that solely worked
for root= and not for the other consumers at that stage.  I'll see if
there is another way around this, but I'm not seeing anything offhand.

thanks!
will
--
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/