Re: identifying module types

[Hollis Blanchard]

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