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