On Tue, 2006-12-12 at 23:28 +0100, Yoshinori K. Okuji wrote: > On Saturday 09 December 2006 01:02, Hollis Blanchard wrote: > > 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?) > > Because the spec does not know how modules are loaded by a boot loader at > all. > It does not know how to configure a boot loader. It does not know whether it > is possible to interact with a boot loader at runtime. On the assumption in > the spec, all we can say is that it is recommended that modules are loaded in > the order specified by the user, if possible. We may not say "must" here.
I guess I'm not clear on this. The modules must be enumerated in some order, whether manually by the user or in a config file or by a script. Wouldn't it be appropriate to require that this order be preserved? Are you envisioning a scenario like a collection of "module" files in a menuentry.d directory, and then what is the order? Xen could go on depending on the ordering, with the caveat that bootloaders which reorder modules won't work. > > 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. > > > > 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; > > Isn't it easier to pass two strings rather than packing them to a single > string? > > type = module->type; > cmdline = module->cmdline; That only works if module->type is of fixed size. What size would you like? Aside from the arbitrary user-visible limit, a fixed size may make namespace collisions more likely (though certainly we would need to account for collisions even if the size were variable). -Hollis _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
