grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: identifying module types


From: Tristan Gingold
Subject: Re: identifying module types
Date: Sat, 9 Dec 2006 06:31:33 +0100
User-agent: Mutt/1.5.9i

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.

> Another alternative would be a NULL-terminated string, which would
> appear in memory just before the NULL-terminated command line, e.g.
>       x e n \0 c o n s o l e = c o m 2 \0
> This is more flexible, but slightly more awkward on the consumer side:
>       type = module_tag->text;
>       cmdline = strchr(module_tag->text, '\0') + 1;
I prefer the use of a fixed-length field.  But that's my own opinion (UUID are
easy to generate, to compare and well-known - do not reinvent the wheel).

Tristan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]