Re: identifying module types

["Yoshinori K. Okuji" <okuji@enbug.org>]

On Tuesday 12 December 2006 21:56, Hollis Blanchard wrote:
> 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 am for making "type"s arbitrary. If one wants to use a "type" as an UUID, 
she can. If one wants to use a "type" as a symbolic name, she can. I think it 
is the most flexible and simplest way to make the interpretation of "type"s 
up to the user.

Okuji