some multiboot2 comments

some multiboot2 comments

[Hollis Blanchard]

http://grub.enbug.org/MultibootDraft

I'm looking at implementing this now.

Module:
Because of the 'length' field in the tag header, the 'reserved' field
isn't actually needed. The 'length' field makes every one of these tag
structures inherently variably sized. Any data added later to this tag
will be skipped over by the reader.

Memory Map:
I'm not sure if we need this. The OS can get this information from
firmware (e.g. BIOS e820 map or Open Firmware) as easily as we can,
right? In general, I don't think we should convert firmware information
into the multiboot structure.

-Hollis

Re: some multiboot2 comments

[Tristan Gingold]

On Thu, Oct 26, 2006 at 02:58:35PM -0500, Hollis Blanchard wrote:
> http://grub.enbug.org/MultibootDraft
> 
> I'm looking at implementing this now.
> 
> Module:
> Because of the 'length' field in the tag header, the 'reserved' field
> isn't actually needed. The 'length' field makes every one of these tag
> structures inherently variably sized. Any data added later to this tag
> will be skipped over by the reader.
Yes.
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]

> Memory Map:
> I'm not sure if we need this. The OS can get this information from
> firmware (e.g. BIOS e820 map or Open Firmware) as easily as we can,
> right? In general, I don't think we should convert firmware information
> into the multiboot structure.
Some platform may need it. On EFI the OS can't get the memmap from EFI because
it is too late.

Tristan.

Re: some multiboot2 comments

[Hollis Blanchard]

On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote:
> On Thu, Oct 26, 2006 at 02:58:35PM -0500, Hollis Blanchard wrote:
> > http://grub.enbug.org/MultibootDraft
> > 
> > I'm looking at implementing this now.
> > 
> > Module:
> > Because of the 'length' field in the tag header, the 'reserved' field
> > isn't actually needed. The 'length' field makes every one of these tag
> > structures inherently variably sized. Any data added later to this tag
> > will be skipped over by the reader.
> Yes.
> 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]

What do you mean by UUID? I certainly would not like to see large magic
numbers required in grub.cfg...

> > Memory Map:
> > I'm not sure if we need this. The OS can get this information from
> > firmware (e.g. BIOS e820 map or Open Firmware) as easily as we can,
> > right? In general, I don't think we should convert firmware information
> > into the multiboot structure.
> Some platform may need it. On EFI the OS can't get the memmap from EFI because
> it is too late.

OK. In that case we're still keeping with the philosophy of only passing
information to the kernel that it can't obtain itself.

-Hollis

Re: some multiboot2 comments

[Yoshinori K. Okuji]

On Friday 27 October 2006 07:37, Hollis Blanchard wrote:
> > Some platform may need it. On EFI the OS can't get the memmap from EFI
> > because it is too late.
>
> OK. In that case we're still keeping with the philosophy of only passing
> information to the kernel that it can't obtain itself.

However, the definition of a memory map varies from architecture to 
architecture, so it might be better to put this tag to architecture-specific 
sections, so that we can redefine the format per architecture.

Okuji

Re: some multiboot2 comments

[Tristan Gingold]

On Fri, Oct 27, 2006 at 12:37:35AM -0500, Hollis Blanchard wrote:
> On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote:
> > On Thu, Oct 26, 2006 at 02:58:35PM -0500, Hollis Blanchard wrote:
> > > http://grub.enbug.org/MultibootDraft
> > > 
> > > I'm looking at implementing this now.
> > > 
> > > Module:
> > > Because of the 'length' field in the tag header, the 'reserved' field
> > > isn't actually needed. The 'length' field makes every one of these tag
> > > structures inherently variably sized. Any data added later to this tag
> > > will be skipped over by the reader.
> > Yes.
> > 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]
> 
> What do you mean by UUID? I certainly would not like to see large magic
> numbers required in grub.cfg...
grub should be aware of the main module types.  For these TYPE is a keyword
such as ramdisk, kernel, xen-acm...
For not yet known types, TYPE can be an UUID.
UUID doesn't require a central administration.  I think this is a real
advantage.

> > > Memory Map:
> > > I'm not sure if we need this. The OS can get this information from
> > > firmware (e.g. BIOS e820 map or Open Firmware) as easily as we can,
> > > right? In general, I don't think we should convert firmware information
> > > into the multiboot structure.
> > Some platform may need it. On EFI the OS can't get the memmap from EFI because
> > it is too late.
> 
> OK. In that case we're still keeping with the philosophy of only passing
> information to the kernel that it can't obtain itself.
Yes.

Tristan.

Re: some multiboot2 comments

[Yoshinori K. Okuji]

On Sunday 29 October 2006 17:38, Tristan Gingold wrote:
> grub should be aware of the main module types.  For these TYPE is a keyword
> such as ramdisk, kernel, xen-acm...
> For not yet known types, TYPE can be an UUID.
> UUID doesn't require a central administration.  I think this is a real
> advantage.

I do not agree. If you want a parameter which may not be interpreted by a boot 
loader, you can simply pass it as an argument to a module. I see no reason 
that this should be part of the spec.

Okuji

Re: some multiboot2 comments

[Tristan Gingold]

On Mon, Oct 30, 2006 at 09:20:55PM +0200, Yoshinori K. Okuji wrote:
> On Sunday 29 October 2006 17:38, Tristan Gingold wrote:
> > grub should be aware of the main module types.  For these TYPE is a keyword
> > such as ramdisk, kernel, xen-acm...
> > For not yet known types, TYPE can be an UUID.
> > UUID doesn't require a central administration.  I think this is a real
> > advantage.
> 
> I do not agree. If you want a parameter which may not be interpreted by a boot 
> loader, you can simply pass it as an argument to a module. I see no reason 
> that this should be part of the spec.
The best raison is to have a unified method to identify a module.  IMHO the
argument line is to be interpreted only by the module.

You know all the parameters can be put into the command line...

Tristan.

Re: some multiboot2 comments

[Yoshinori K. Okuji]

On Monday 30 October 2006 21:24, Tristan Gingold wrote:
> The best raison is to have a unified method to identify a module.  IMHO the
> argument line is to be interpreted only by the module.
>
> You know all the parameters can be put into the command line...

So you don't want to mix up arguments to a module itself and arguments to a 
kernel. This makes sense. Can you propose how to pass this information 
exactly?

BTW, raison is French. ;)

Okuji

Re: some multiboot2 comments

[Tristan Gingold]

On Thu, Nov 02, 2006 at 09:52:02PM +0200, Yoshinori K. Okuji wrote:
> On Monday 30 October 2006 21:24, Tristan Gingold wrote:
> > The best raison is to have a unified method to identify a module.  IMHO the
> > argument line is to be interpreted only by the module.
> >
> > You know all the parameters can be put into the command line...
> 
> So you don't want to mix up arguments to a module itself and arguments to a 
> kernel. This makes sense. Can you propose how to pass this information 
> exactly?
Using the multiboot draft, we may add new K/L/D fields within the module KLD.

> BTW, raison is French. ;)
I am not very sure...

Tristan.

Re: identifying module types

[Hollis Blanchard]

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

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.

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;

-Hollis

Re: identifying module types

[Tristan Gingold]

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.

Re: identifying module types

[Hollis Blanchard]

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 prefer the use of a fixed-length field.

Me too.

> But that's my own opinion (UUID are
> easy to generate, to compare and well-known - do not reinvent the wheel).

UUIDs, e.g.  550e8400-e29b-41d4-a716-446655440000, are also completely
unintelligible, so they cannot be the only answer.

So far you seem to be advocating the following:
        module [--type TYPE | --uuid UUID] file
        
TYPE: an English word that GRUB translates to a UUID. GRUB must therefor
maintain a table of known types and their associated UUIDs.
UUID: a 16-byte number which can be represented as 36 ASCII characters
(including hyphens).

How should we generate the UUIDs for the table in GRUB? I'll just run
uuidgen here and create them myself?

Does anybody object to this scheme?

-Hollis

Re: identifying module types

[Yoshinori K. Okuji]

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

Re: identifying module types

[Hollis Blanchard]

On Tue, 2006-12-12 at 23:54 +0100, Yoshinori K. Okuji wrote:
> 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. 

Makes sense to me. We should make sure we have at least 32 bytes of type
to represent 16-byte UUIDs in ASCII, and ideally 36 to accommodate the
four hyphens.

-Hollis

Re: identifying module types

[Tristan Gingold]

On Tue, Dec 12, 2006 at 11:54:41PM +0100, Yoshinori K. Okuji wrote:
> 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:
[...]
> 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.
I am not against this proposal.  I just could object we'd better to have
a mechanism to avoid collision.  If the "type" is a string collisions would
appear really soon.

Tristan.

Re: identifying module types

[Tristan Gingold]

[Sorry for the late reply]
On Tue, Dec 12, 2006 at 02:56:10PM -0600, 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:
[...]
> > > 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.
You have exposed it just below better than I could.
 
> > I prefer the use of a fixed-length field.
> 
> Me too.
> 
> > But that's my own opinion (UUID are
> > easy to generate, to compare and well-known - do not reinvent the wheel).
> 
> UUIDs, e.g.  550e8400-e29b-41d4-a716-446655440000, are also completely
> unintelligible, so they cannot be the only answer.
Sure.
 
> So far you seem to be advocating the following:
>         module [--type TYPE | --uuid UUID] file
>         
> TYPE: an English word that GRUB translates to a UUID. GRUB must therefor
> maintain a table of known types and their associated UUIDs.
> UUID: a 16-byte number which can be represented as 36 ASCII characters
> (including hyphens).
> 
> How should we generate the UUIDs for the table in GRUB? I'll just run
> uuidgen here and create them myself?
Yes.

> Does anybody object to this scheme?
Tristan.

Re: identifying module types

[Hollis Blanchard]

On Fri, 2006-12-08 at 18:02 -0600, 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?) 

Of course, requiring that the order be preserved is the simplest
solution, so unless there is a compelling reason to avoid that, I think
we should avoid the UUID complexity.

-Hollis

Re: identifying module types

[Tristan Gingold]

On Tue, Dec 12, 2006 at 03:48:34PM -0600, Hollis Blanchard wrote:
> On Fri, 2006-12-08 at 18:02 -0600, 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?) 
> 
> Of course, requiring that the order be preserved is the simplest
> solution, so unless there is a compelling reason to avoid that, I think
> we should avoid the UUID complexity.
I don't agree here.  Preserving the order is not enough.  The best example
is Xen: even if we agree that the first module is the dom0 kernel, the second
module may be either the dom0 initrd *or* the acm configuration file.  Both
are optional.

Tristan.

Re: identifying module types

[Yoshinori K. Okuji]

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.

> 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;

Okuji

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

Re: identifying module types

[Yoshinori K. Okuji]

On Wednesday 13 December 2006 01:07, Hollis Blanchard wrote:
> 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?

The problem is that there is no universal way to specify what an "order 
specified by the user" means. If the spec defines that it is a must, the spec 
must specify how a boot loader accepts user input, etc.

> Are you envisioning a scenario like a collection of "module" files in a
> menuentry.d directory, and then what is the order?

Not really, but I think this is a good point.

> Xen could go on depending on the ordering, with the caveat that
> bootloaders which reorder modules won't work.

I agree.

> That only works if module->type is of fixed size. What size would you
> like?

Ah, I got it. So it is necessary to terminate a type with a NUL value and pack 
it into a tag.

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

Right.

Okuji

Re: some multiboot2 comments

[Yoshinori K. Okuji]

On Thursday 26 October 2006 21:58, Hollis Blanchard wrote:
> Module:
> Because of the 'length' field in the tag header, the 'reserved' field
> isn't actually needed. The 'length' field makes every one of these tag
> structures inherently variably sized. Any data added later to this tag
> will be skipped over by the reader.

Only if you can specify tag size separately. In the current draft, the size of 
a tag is defined by "length" which describes the real size of the content. So 
if we don't include "reserved", there is no additional space for the future, 
except for a possible padding.

Okuji

Re: some multiboot2 comments

[Hollis Blanchard]

On Sat, 2006-10-28 at 16:11 +0200, Yoshinori K. Okuji wrote:
> On Thursday 26 October 2006 21:58, Hollis Blanchard wrote:
> > Module:
> > Because of the 'length' field in the tag header, the 'reserved' field
> > isn't actually needed. The 'length' field makes every one of these tag
> > structures inherently variably sized. Any data added later to this tag
> > will be skipped over by the reader.
> 
> Only if you can specify tag size separately. In the current draft, the size of 
> a tag is defined by "length" which describes the real size of the content. So 
> if we don't include "reserved", there is no additional space for the future, 
> except for a possible padding.

Are you saying that given tag->key == foo, tag->length == sizeof(struct
tag_foo)? I think it makes far more sense to allow 'length' to be
independent of 'key', and that means we don't need this 'reserved'
stuff.

If 'length' is always sizeof(something), then we might as well drop
'length' entirely, and I don't think that would be a good idea.

-Hollis

Re: some multiboot2 comments

[Yoshinori K. Okuji]

On Saturday 28 October 2006 20:32, Hollis Blanchard wrote:
> Are you saying that given tag->key == foo, tag->length == sizeof(struct
> tag_foo)? I think it makes far more sense to allow 'length' to be
> independent of 'key', and that means we don't need this 'reserved'
> stuff.

'length' is sometimes somehow independent. When passing data whose size is 
variable, 'length' specifies the size. The size of an item is indirectly 
defined by 'length'. The size of an item can be different from the size of 
data, because of a padding for an alignment.

Okuji

Re: some multiboot2 comments

[Hollis Blanchard]

On Mon, 2006-10-30 at 21:15 +0200, Yoshinori K. Okuji wrote:
> On Saturday 28 October 2006 20:32, Hollis Blanchard wrote:
> > Are you saying that given tag->key == foo, tag->length == sizeof(struct
> > tag_foo)? I think it makes far more sense to allow 'length' to be
> > independent of 'key', and that means we don't need this 'reserved'
> > stuff.
> 
> 'length' is sometimes somehow independent. When passing data whose size is 
> variable, 'length' specifies the size. The size of an item is indirectly 
> defined by 'length'. The size of an item can be different from the size of 
> data, because of a padding for an alignment.

That definition doesn't take advantage of the flexibility 'length' could
give us. We should be able to use arbitrary values for 'length', even
when the tag structure size is well-defined. There is no reason not
to...

-Hollis

Re: some multiboot2 comments

[Yoshinori K. Okuji]

On Tuesday 31 October 2006 02:43, Hollis Blanchard wrote:
> On Mon, 2006-10-30 at 21:15 +0200, Yoshinori K. Okuji wrote:
> > On Saturday 28 October 2006 20:32, Hollis Blanchard wrote:
> > > Are you saying that given tag->key == foo, tag->length == sizeof(struct
> > > tag_foo)? I think it makes far more sense to allow 'length' to be
> > > independent of 'key', and that means we don't need this 'reserved'
> > > stuff.
> >
> > 'length' is sometimes somehow independent. When passing data whose size
> > is variable, 'length' specifies the size. The size of an item is
> > indirectly defined by 'length'. The size of an item can be different from
> > the size of data, because of a padding for an alignment.
>
> That definition doesn't take advantage of the flexibility 'length' could
> give us. We should be able to use arbitrary values for 'length', even
> when the tag structure size is well-defined. There is no reason not
> to...

Right.

Okuji