Re: GPT attributes in dkwedge [PATCH]

[mlelstv%serpens.de@localhost (Michael van Elst)]

martin%duskware.de@localhost (Martin Husemann) writes:

>But the more general solution (which would be just as easy for the end
>user, but more flexibel) is to add support for a rootdev statement
>in boot.cfg and then put the label name or the guid there. Similar
>to evbarm taking a root=dev argument passed from the bootloarder.

You can already specify the root in boot.cfg.


>It would also be cool if boot.cfg could specify the partition to load
>the kernel from via something similiar to NAME=.

You can already specify the disk to load the kernel from with NAME=.



>You insist on this not working for multiboot (which I understand), but I

Multiboot specifies a BIOS drive number and 2 (or 3) partition numbers,
the interpretation of the partition numbers is not really defined
but commonly it's as MBR partition number (1..4 for primary 5+ for extended)
and optionally a BSD disklabel partition number (assuming the primary
partition happens to be identified as *BSD*).

That isn't really flexible or abstract enough or matches the
raidframe scenario and trying to do so (by fixing an interpretation)
is the wrong way to go.



>don't understand how you get this far at all with multiboot. And I think
>multiboot can pass a command line, so root=dev support and make it equivalent
>to the boot.cfg rootdev statement would solve it too.

The multiboot support code in the kernel already interprets the passed
command line, including a "root" option, and this also allows to pass
a wedge name.


There is one caveat. Since all x86 bootloader data is funneled through
the bootinfo structure we have:

struct btinfo_rootdevice {      
        struct btinfo_common common;
        char devname[16];       
};

So we have 16 chars to store the identifier (including a NAME= or
wedge: prefix), that's not enough for a UUID.