[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: identifying module types

From: Hollis Blanchard
Subject: Re: identifying module types
Date: Tue, 12 Dec 2006 18:07:26 -0600

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

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]