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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel