Re: identifying module types

[Hollis Blanchard]

On Sat, 2006-12-09 at 06:31 +0100, Tristan Gingold wrote:
> On Fri, Dec 08, 2006 at 06:02:31PM -0600, Hollis Blanchard wrote:
> > On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote:
> > > BTW, why not adding a type field for module tag.  The type (which should 
> > > be
> > > an UUID IMHO) should indicate the type of the module.
> > > One usage could be for Xen.  On Xen you can load 3 modules: the linux 
> > > kernel,
> > > the linux ramdisk and an ACM configuration.  Xen relies on order and on 
> > > some
> > > magic checks to find the module type.
> > > The command syntax could be:
> > > module [-type TYPE] file [cmdline]
> > 
> > As I'm implementing the Xen side of this, I can now see the need.
> > 
> > Xen uses a handful of modules:
> > - xen kernel
> > - dom0 kernel
> > - dom0 initrd
> > - security policy (binary blob)
> > - possibly others
> > 
> > On the consumer side of multiboot (in this case Xen), we need to loop
> > over the tags, and when we find a module tag, how do we know which it
> > is? The Multiboot2 spec tells us "The order of modules is not
> > guaranteed." (Why not?)
> Currently Xen relies on the order.  Maybe the spec should be slighly changed?
> 
> > If we can't rely on the order, then we have no reliable way to
> > distinguish the type of module we're looking at, so a type field would
> > be extremely useful. For example:
> >     multiboot (hd1,1)/xen
> >     module -t xenhv-dom0 (hd1,1)/vmlinux
> >     module -t xenhv-dom0-initrd (hd1,1)/initrd
> > or
> >     multiboot (hd0,0)/boot/gnumach.gz root=device:hd2s1
> >     module -t hurd-something (hd0,0)/lib/ld.so.1
> > 
> > One option is a fixed-length encoded field, say 32 bytes wide. To avoid
> > namespace collisions, we could require that projects prefix types with
> > their project name, which must be at least 4 bytes.
> Nb: UUID are 16 bytes and collisions are avoided.

Please detail your proposal.

> I prefer the use of a fixed-length field.

Me too.

> But that's my own opinion (UUID are
> easy to generate, to compare and well-known - do not reinvent the wheel).

UUIDs, e.g.  550e8400-e29b-41d4-a716-446655440000, are also completely
unintelligible, so they cannot be the only answer.

So far you seem to be advocating the following:
        module [--type TYPE | --uuid UUID] file
        
TYPE: an English word that GRUB translates to a UUID. GRUB must therefor
maintain a table of known types and their associated UUIDs.
UUID: a 16-byte number which can be represented as 36 ASCII characters
(including hyphens).

How should we generate the UUIDs for the table in GRUB? I'll just run
uuidgen here and create them myself?

Does anybody object to this scheme?

-Hollis