[Top][All Lists]
[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.