multiboot2: make multiboot header optional

multiboot2: make multiboot header optional

[Hollis Blanchard]

I would like to make the in-kernel multiboot header optional. If it's an
ELF file, we can load it, even if it doesn't have the header. We can
also pass the address of the multiboot tags to its entry point (it can't
hurt anything).

For kernels that need to communicate information to GRUB (e.g.
"vga_mode" from my previous email, or a.out load addresses), the
multiboot header would be needed for GRUB to locate the parameter area
within the executable.

-Hollis

Re: multiboot2: make multiboot header optional

[Johan Rydberg]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hollis Blanchard <hollis@penguinppc.org> writes:

> For kernels that need to communicate information to GRUB (e.g.
> "vga_mode" from my previous email, or a.out load addresses), the
> multiboot header would be needed for GRUB to locate the parameter area
> within the executable.

My two cents;

In MB2 we remove the possibility to communicate options from the
kernel to the boot loader.  The loader has one task; loading the
kernel and leave control to it, and possible pass information about
the environment.  Nothing more.

If the operating system kernel is stupid enough to require as special
video mode the user should be aware of that and setup the bootloader
so that it is in that mode before the kernel is started.

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Wed, 2006-11-15 at 09:57 +0100, Johan Rydberg wrote:
> Hollis Blanchard <hollis@penguinppc.org> writes:
> 
> > For kernels that need to communicate information to GRUB (e.g.
> > "vga_mode" from my previous email, or a.out load addresses), the
> > multiboot header would be needed for GRUB to locate the parameter area
> > within the executable.
> 
> My two cents;
> 
> In MB2 we remove the possibility to communicate options from the
> kernel to the boot loader.  The loader has one task; loading the
> kernel and leave control to it, and possible pass information about
> the environment.  Nothing more.
> 
> If the operating system kernel is stupid enough to require as special
> video mode the user should be aware of that and setup the bootloader
> so that it is in that mode before the kernel is started.

The only information in the multiboot header is a) the load addresses
for a.out and "other" formats, and b) the VGA info.

We could certainly drop the VGA info.

I don't think it would be a big deal to drop a.out as well; I don't know
of any modern OS that uses these, and anyways kernel builds are special.
However (and I don't know how reasonable this is), Mac OS X's toolchain
will build only Mach-O binaries, so one would be unable to build a
kernel that GRUB could load. We could require a Mach-O loader in that
case, but I will admit that the "a.out hack" multiboot header fields
simplify this problem.

If we do require format-specific loaders, the multiboot2 loader could
just be renamed to "elf", leaving the legacy i386 multiboot loader
intact.

To support straight binary kernels with a "binary" loader, the kernel
could be loaded at e.g. 0x7c00 (on x86) and passed the multiboot tags.

-Hollis

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Tuesday 14 November 2006 23:58, Hollis Blanchard wrote:
> I would like to make the in-kernel multiboot header optional. If it's an
> ELF file, we can load it, even if it doesn't have the header. We can
> also pass the address of the multiboot tags to its entry point (it can't
> hurt anything).

I prefer to keep a multiboot header, because GRUB may not detect an error that 
the offset of a multiboot header is beyond 8192 bytes.

Okuji

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
> > If the operating system kernel is stupid enough to require as special
> > video mode the user should be aware of that and setup the bootloader
> > so that it is in that mode before the kernel is started.
>
> The only information in the multiboot header is a) the load addresses
> for a.out and "other" formats, and b) the VGA info.
>
> We could certainly drop the VGA info.

No. The problem is that a kernel cannot initialize VESA in protected mode in 
some BIOSes. If you need more info, please dig into the archive of bug-grub.

> I don't think it would be a big deal to drop a.out as well; I don't know
> of any modern OS that uses these, and anyways kernel builds are special.
> However (and I don't know how reasonable this is), Mac OS X's toolchain
> will build only Mach-O binaries, so one would be unable to build a
> kernel that GRUB could load. We could require a Mach-O loader in that
> case, but I will admit that the "a.out hack" multiboot header fields
> simplify this problem.

Never drop the a.out kludge. This flexibility is one of the advantages in 
Multiboot. Note that GRUB itself uses this feature.

Okuji

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Wed, 2006-11-15 at 22:42 +0200, Yoshinori K. Okuji wrote:
> On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
> > > If the operating system kernel is stupid enough to require as special
> > > video mode the user should be aware of that and setup the bootloader
> > > so that it is in that mode before the kernel is started.
> >
> > The only information in the multiboot header is a) the load addresses
> > for a.out and "other" formats, and b) the VGA info.
> >
> > We could certainly drop the VGA info.
> 
> No. The problem is that a kernel cannot initialize VESA in protected mode in 
> some BIOSes. If you need more info, please dig into the archive of bug-grub.

OK, that is unfortunate.

> > I don't think it would be a big deal to drop a.out as well; I don't know
> > of any modern OS that uses these, and anyways kernel builds are special.
> > However (and I don't know how reasonable this is), Mac OS X's toolchain
> > will build only Mach-O binaries, so one would be unable to build a
> > kernel that GRUB could load. We could require a Mach-O loader in that
> > case, but I will admit that the "a.out hack" multiboot header fields
> > simplify this problem.
> 
> Never drop the a.out kludge. This flexibility is one of the advantages in 
> Multiboot. Note that GRUB itself uses this feature.

I still would like an improvement in the kernel->GRUB communication.
What about reusing the tags structure? For example:

multiboot_header:
	.long MAGIC
	.long MULTIBOOT_TAG_START [...]
	.long MULTIBOOT_TAG_LOADADDR ; .long 12 ; .long _start
	.long MULTIBOOT_TAG_ENTRYADDR ; .long 12 ; .long main
	.long MULTIBOOT_TAG_END ; .long 8
etc?

A cpp macro or two could make that a little more convenient.

The fact that the START tag requires the number of tags and number of
bytes is inconvenient here. Do we really need that? Why not just:

        while (tag->key != MULTIBOOT_TAG_END)
                process_tag(tag);

-Hollis

Re: multiboot2: make multiboot header optional

[tgingold]

Quoting Hollis Blanchard <hollis@penguinppc.org>:

> On Wed, 2006-11-15 at 22:42 +0200, Yoshinori K. Okuji wrote:
> > On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
[...]
> > > I don't think it would be a big deal to drop a.out as well; I don't know
> > > of any modern OS that uses these, and anyways kernel builds are special.
> > > However (and I don't know how reasonable this is), Mac OS X's toolchain
> > > will build only Mach-O binaries, so one would be unable to build a
> > > kernel that GRUB could load. We could require a Mach-O loader in that
> > > case, but I will admit that the "a.out hack" multiboot header fields
> > > simplify this problem.
> >
> > Never drop the a.out kludge. This flexibility is one of the advantages in
> > Multiboot. Note that GRUB itself uses this feature.
>
> I still would like an improvement in the kernel->GRUB communication.
> What about reusing the tags structure? For example:
>
> multiboot_header:
> 	.long MAGIC
> 	.long MULTIBOOT_TAG_START [...]
> 	.long MULTIBOOT_TAG_LOADADDR ; .long 12 ; .long _start
> 	.long MULTIBOOT_TAG_ENTRYADDR ; .long 12 ; .long main
> 	.long MULTIBOOT_TAG_END ; .long 8
> etc?
>
> A cpp macro or two could make that a little more convenient.
>
> The fact that the START tag requires the number of tags and number of
> bytes is inconvenient here. Do we really need that? Why not just:
>
>         while (tag->key != MULTIBOOT_TAG_END)
>                 process_tag(tag);
I really like such tags structure.
Tags structure are *very* flexible: can be easily extended without breaking
backward compatibility.

Tristan.

Re: multiboot2: make multiboot header optional

[tgingold]

Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:

> On Tuesday 14 November 2006 23:58, Hollis Blanchard wrote:
> > I would like to make the in-kernel multiboot header optional. If it's an
> > ELF file, we can load it, even if it doesn't have the header. We can
> > also pass the address of the multiboot tags to its entry point (it can't
> > hurt anything).
>
> I prefer to keep a multiboot header, because GRUB may not detect an error
> that
> the offset of a multiboot header is beyond 8192 bytes.
BTW, on ia64 8192 is too small.  Linux and Xen put the ivt (interrupt vector
table) at the head of the file because it has the largest alignment
requirement (32Kb).  I am not sure there is a big enough hole in the ivt.
And Xen has two ivt (-> 64kB).
However both Linux and Xen use the ELF format.

Tristan.

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Thu, 2006-11-16 at 00:41 +0100, tgingold@free.fr wrote:
> Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:
> 
> > On Tuesday 14 November 2006 23:58, Hollis Blanchard wrote:
> > > I would like to make the in-kernel multiboot header optional. If it's an
> > > ELF file, we can load it, even if it doesn't have the header. We can
> > > also pass the address of the multiboot tags to its entry point (it can't
> > > hurt anything).
> >
> > I prefer to keep a multiboot header, because GRUB may not detect an error
> > that the offset of a multiboot header is beyond 8192 bytes.
> BTW, on ia64 8192 is too small.  Linux and Xen put the ivt (interrupt vector
> table) at the head of the file because it has the largest alignment
> requirement (32Kb).  I am not sure there is a big enough hole in the ivt.
> And Xen has two ivt (-> 64kB).
> However both Linux and Xen use the ELF format.

Do you have a proposal to solve this problem? Are you advocating
dropping the multiboot header, since we can load ELF files without it?

-Hollis

Re: multiboot2: make multiboot header optional

[tgingold]

Quoting Hollis Blanchard <hollis@penguinppc.org>:

> On Thu, 2006-11-16 at 00:41 +0100, tgingold@free.fr wrote:
> > Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:
> >
> > > On Tuesday 14 November 2006 23:58, Hollis Blanchard wrote:
> > > > I would like to make the in-kernel multiboot header optional. If it's
> an
> > > > ELF file, we can load it, even if it doesn't have the header. We can
> > > > also pass the address of the multiboot tags to its entry point (it
> can't
> > > > hurt anything).
> > >
> > > I prefer to keep a multiboot header, because GRUB may not detect an error
> > > that the offset of a multiboot header is beyond 8192 bytes.
> > BTW, on ia64 8192 is too small.  Linux and Xen put the ivt (interrupt
> vector
> > table) at the head of the file because it has the largest alignment
> > requirement (32Kb).  I am not sure there is a big enough hole in the ivt.
> > And Xen has two ivt (-> 64kB).
> > However both Linux and Xen use the ELF format.
>
> Do you have a proposal to solve this problem? Are you advocating
> dropping the multiboot header, since we can load ELF files without it?
I am advocating dropping multiboot header on ia64 *only*.  Basically even if
we implement it, nobody will use it.

Tristan.

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Thursday 16 November 2006 00:38, tgingold@free.fr wrote:
> > I still would like an improvement in the kernel->GRUB communication.
> > What about reusing the tags structure? For example:
> >
> > multiboot_header:
> > 	.long MAGIC
> > 	.long MULTIBOOT_TAG_START [...]
> > 	.long MULTIBOOT_TAG_LOADADDR ; .long 12 ; .long _start
> > 	.long MULTIBOOT_TAG_ENTRYADDR ; .long 12 ; .long main
> > 	.long MULTIBOOT_TAG_END ; .long 8
> > etc?
> >
> > A cpp macro or two could make that a little more convenient.
> >
> > The fact that the START tag requires the number of tags and number of
> > bytes is inconvenient here. Do we really need that? Why not just:
> >
> >         while (tag->key != MULTIBOOT_TAG_END)
> >                 process_tag(tag);
>
> I really like such tags structure.
> Tags structure are *very* flexible: can be easily extended without breaking
> backward compatibility.

I don't like it very much. My first draft was exactly like this. But, after 
some discussion in the IRC, I decided to revert my idea, because specifying 
so many parameters by hand really sucks. It is too error-prone.

Okuji

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Thursday 16 November 2006 00:41, tgingold@free.fr wrote:
> BTW, on ia64 8192 is too small.  Linux and Xen put the ivt (interrupt
> vector table) at the head of the file because it has the largest alignment
> requirement (32Kb).  I am not sure there is a big enough hole in the ivt.
> And Xen has two ivt (-> 64kB).
> However both Linux and Xen use the ELF format.

I fail to see why. Why is it necessary to put the table _physically_ at the 
head?

Okuji

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Tuesday 21 November 2006 18:35, tgingold@free.fr wrote:
> > Do you have a proposal to solve this problem? Are you advocating
> > dropping the multiboot header, since we can load ELF files without it?
>
> I am advocating dropping multiboot header on ia64 *only*.  Basically even
> if we implement it, nobody will use it.

I don't like this. If we drop it, we should do it on all architectures. If we 
don't, we should keep it on all architectures. We should make it consistent.

Okuji

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Sat, 2006-11-25 at 03:59 +0100, Yoshinori K. Okuji wrote:
> On Thursday 16 November 2006 00:38, tgingold@free.fr wrote:
> > > I still would like an improvement in the kernel->GRUB communication.
> > > What about reusing the tags structure? For example:
> > >
> > > multiboot_header:
> > > 	.long MAGIC
> > > 	.long MULTIBOOT_TAG_START [...]
> > > 	.long MULTIBOOT_TAG_LOADADDR ; .long 12 ; .long _start
> > > 	.long MULTIBOOT_TAG_ENTRYADDR ; .long 12 ; .long main
> > > 	.long MULTIBOOT_TAG_END ; .long 8
> > > etc?
> > >
> > > A cpp macro or two could make that a little more convenient.
> > >
> > > The fact that the START tag requires the number of tags and number of
> > > bytes is inconvenient here. Do we really need that? Why not just:
> > >
> > >         while (tag->key != MULTIBOOT_TAG_END)
> > >                 process_tag(tag);
> >
> > I really like such tags structure.
> > Tags structure are *very* flexible: can be easily extended without breaking
> > backward compatibility.
> 
> I don't like it very much. My first draft was exactly like this. But, after 
> some discussion in the IRC, I decided to revert my idea, because specifying 
> so many parameters by hand really sucks. It is too error-prone.

Bits are less error-prone?

How about this:
        MB_START_TAGS()
        MB_LOADADDR(0x1234)
        MB_ENTRYADDR(0x1234)
        MB_END_TAGS()

-Hollis

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Saturday 25 November 2006 04:35, Hollis Blanchard wrote:
> > I don't like it very much. My first draft was exactly like this. But,
> > after some discussion in the IRC, I decided to revert my idea, because
> > specifying so many parameters by hand really sucks. It is too
> > error-prone.
>
> Bits are less error-prone?

Less typing is less error-prone.

> How about this:
>         MB_START_TAGS()
>         MB_LOADADDR(0x1234)
>         MB_ENTRYADDR(0x1234)
>         MB_END_TAGS()

How to abbreviate information does not matter. When one implements an OS, she 
must put the definition at somewhere anyway. Even if we provide a sample 
implementation, not all people won't use it, because there are various 
assemblers and compilers. For example, if our example is for GNU as, nasm 
users won't use it. So the spec must be simple.

Okuji

Re: multiboot2: make multiboot header optional

[Tristan Gingold]

On Sat, Nov 25, 2006 at 04:00:28AM +0100, Yoshinori K. Okuji wrote:
> On Thursday 16 November 2006 00:41, tgingold@free.fr wrote:
> > BTW, on ia64 8192 is too small.  Linux and Xen put the ivt (interrupt
> > vector table) at the head of the file because it has the largest alignment
> > requirement (32Kb).  I am not sure there is a big enough hole in the ivt.
> > And Xen has two ivt (-> 64kB).
> > However both Linux and Xen use the ELF format.
> 
> I fail to see why. Why is it necessary to put the table _physically_ at the 
> head?
Because:
* it is done so!
* it has the biggest alignment constraint.

Theorically it is not required, but everyone do that.

Tristan.

Re: multiboot2: make multiboot header optional

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
>> > If the operating system kernel is stupid enough to require as special
>> > video mode the user should be aware of that and setup the bootloader
>> > so that it is in that mode before the kernel is started.
>>
>> The only information in the multiboot header is a) the load addresses
>> for a.out and "other" formats, and b) the VGA info.
>>
>> We could certainly drop the VGA info.
>
> No. The problem is that a kernel cannot initialize VESA in protected mode in 
> some BIOSes. If you need more info, please dig into the archive of bug-grub.

Right, but now the kernel tells the user while video mode to use.  So
either it is hardcoded in the kernel, or the user has to change the
kernel to change video modes.  I think this is weird and this was
never implemented this way.

What I prefer is making it possible for the user to select the video
mode.  In that case the kernel will become a bit more complex, because
it has to deal with more situations, but I do not really see this as a
problem.

--
Marco

Re: multiboot2: make multiboot header optional

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Saturday 25 November 2006 04:35, Hollis Blanchard wrote:
>> > I don't like it very much. My first draft was exactly like this. But,
>> > after some discussion in the IRC, I decided to revert my idea, because
>> > specifying so many parameters by hand really sucks. It is too
>> > error-prone.
>>
>> Bits are less error-prone?
>
> Less typing is less error-prone.

What is the problem with typing?  I do not think this is really
complex?  And this is just in the initial stage of the implementation
of an operating system.  I don't think this is a problem, I think
something that is clear from the context, which is the case in Hollis'
proposal will prevent such errors.

>> How about this:
>>         MB_START_TAGS()
>>         MB_LOADADDR(0x1234)
>>         MB_ENTRYADDR(0x1234)
>>         MB_END_TAGS()
>
> How to abbreviate information does not matter. When one implements an OS, she 
> must put the definition at somewhere anyway. Even if we provide a sample 
> implementation, not all people won't use it, because there are various 
> assemblers and compilers. For example, if our example is for GNU as, nasm 
> users won't use it. So the spec must be simple.

Can't this be done with nasm?

--
Marco

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Saturday 02 December 2006 17:15, Marco Gerards wrote:
> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
> > On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
> >> > If the operating system kernel is stupid enough to require as special
> >> > video mode the user should be aware of that and setup the bootloader
> >> > so that it is in that mode before the kernel is started.
> >>
> >> The only information in the multiboot header is a) the load addresses
> >> for a.out and "other" formats, and b) the VGA info.
> >>
> >> We could certainly drop the VGA info.
> >
> > No. The problem is that a kernel cannot initialize VESA in protected mode
> > in some BIOSes. If you need more info, please dig into the archive of
> > bug-grub.
>
> Right, but now the kernel tells the user while video mode to use.  So
> either it is hardcoded in the kernel, or the user has to change the
> kernel to change video modes.  I think this is weird and this was
> never implemented this way.
>
> What I prefer is making it possible for the user to select the video
> mode.  In that case the kernel will become a bit more complex, because
> it has to deal with more situations, but I do not really see this as a
> problem.

Please read the spec carefully. It only specifies what an OS image prefers. 
Since this is a spec, it does not define what happens when the user specifies 
something else in a config file or interactively, but it recommends 
overriding the preference by the user's input.

Why this is useful has been discussed in bug-grub a long, long time ago, and 
I'm not willing to repeat the same discussion again. So, if you don't agree, 
first dig into the archive. If you think it's too boring, just trust me.

Okuji

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Saturday 02 December 2006 17:18, Marco Gerards wrote:
> What is the problem with typing?  I do not think this is really
> complex?

Weird. It was _you_ who pointed out that specifying tags would be annoying on 
the IRC...

> And this is just in the initial stage of the implementation 
> of an operating system.  I don't think this is a problem, I think
> something that is clear from the context, which is the case in Hollis'
> proposal will prevent such errors.

I do think it is a problem. Whether it is a small portion in OS development or 
not does not matter. If it is problematic, it is.

Reversely, I ask you a question. What is the real advantage in using tags in a 
Multiboot header?

From my point of view, it is not necessarily very extensible or flexible, as 
our experience shows that changes to the Multiboot header are rarely demanded 
(so far, only once, IIRC).

> > How to abbreviate information does not matter. When one implements an OS,
> > she must put the definition at somewhere anyway. Even if we provide a
> > sample implementation, not all people won't use it, because there are
> > various assemblers and compilers. For example, if our example is for GNU
> > as, nasm users won't use it. So the spec must be simple.
>
> Can't this be done with nasm?

Don't take my words literaly. I just put nasm as an example. There are plenty 
of different languages, and would you like to provide sample code for _all_ 
languages in the world?

Okuji

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Sat, 2006-12-02 at 18:27 +0100, Yoshinori K. Okuji wrote:
> 
> Reversely, I ask you a question. What is the real advantage in using
> tags in a Multiboot header?
> 
> From my point of view, it is not necessarily very extensible or
> flexible, as our experience shows that changes to the Multiboot header
> are rarely demanded (so far, only once, IIRC).

It should be pretty clear that 32 bits are a finite number, and tags are
unlimited. In fact it's worse than that, since the bit partitioning
means we have far fewer available bits for any particular flag.

The bit numbering is also confusing, especially the partitioning of
meanings (this is required, this is requested, this is arch-specific,
this isn't).

Finally, using flags for some things and tags for others is
inconsistent.

The extensibility argument alone is enough to seal it for me, especially
since the code can be written in such an error-free manner, as I've
demonstrated.

-Hollis

Re: multiboot2: make multiboot header optional

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Saturday 02 December 2006 17:18, Marco Gerards wrote:
>> What is the problem with typing?  I do not think this is really
>> complex?
>
> Weird. It was _you_ who pointed out that specifying tags would be annoying on 
> the IRC...

I am all for something that is simple.  Initially it looked like
Hollis' proposal was more complex, but IIRC he mentioned he wanted to
work on making this easier to use.  Isn't this what he did?  Or did I
misunderstand something?  If someone (Hollis in this case) thinks I am
wrong and comes with a good argumentation, I am always willing to
change my opinion.

>> And this is just in the initial stage of the implementation 
>> of an operating system.  I don't think this is a problem, I think
>> something that is clear from the context, which is the case in Hollis'
>> proposal will prevent such errors.
>
> I do think it is a problem. Whether it is a small portion in OS development or 
> not does not matter. If it is problematic, it is.
>
> Reversely, I ask you a question. What is the real advantage in using tags in a 
> Multiboot header?

Actually, Hollis tried to proof we do not need a header at all.  I
personally find this an interesting option to discuss.

>>From my point of view, it is not necessarily very extensible or flexible, as 
> our experience shows that changes to the Multiboot header are rarely demanded 
> (so far, only once, IIRC).
>
>> > How to abbreviate information does not matter. When one implements an OS,
>> > she must put the definition at somewhere anyway. Even if we provide a
>> > sample implementation, not all people won't use it, because there are
>> > various assemblers and compilers. For example, if our example is for GNU
>> > as, nasm users won't use it. So the spec must be simple.
>>
>> Can't this be done with nasm?
>
> Don't take my words literaly. I just put nasm as an example. There are plenty 
> of different languages, and would you like to provide sample code for _all_ 
> languages in the world?

No, but in that other case the header can't be generated and it will
be harder.  But I think we have to optimize for the common case.

--
Marco

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Mon, 2006-12-04 at 21:35 +0100, Marco Gerards wrote:
> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
> 
> > On Saturday 02 December 2006 17:18, Marco Gerards wrote:
> >> What is the problem with typing?  I do not think this is really
> >> complex?
> >
> > Weird. It was _you_ who pointed out that specifying tags would be
> annoying on 
> > the IRC...
> 
> I am all for something that is simple.  Initially it looked like
> Hollis' proposal was more complex, but IIRC he mentioned he wanted to
> work on making this easier to use.  Isn't this what he did?  Or did I
> misunderstand something?  If someone (Hollis in this case) thinks I am
> wrong and comes with a good argumentation, I am always willing to
> change my opinion.

I already illustrated how easy it is:
        MB_HEADER()
        MB_START_TAGS()
        MB_LOADADDR(0x1234)
        MB_ENTRYADDR(0x1234)
        MB_END_TAGS()

Please explain if you think this it too difficult.

Note: I refuse to believe that ORing flags into a .long is less complex.

-Hollis

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Tuesday 05 December 2006 20:09, Hollis Blanchard wrote:
> > I am all for something that is simple.  Initially it looked like
> > Hollis' proposal was more complex, but IIRC he mentioned he wanted to
> > work on making this easier to use.  Isn't this what he did?  Or did I
> > misunderstand something?  If someone (Hollis in this case) thinks I am
> > wrong and comes with a good argumentation, I am always willing to
> > change my opinion.
>
> I already illustrated how easy it is:
>         MB_HEADER()
>         MB_START_TAGS()
>         MB_LOADADDR(0x1234)
>         MB_ENTRYADDR(0x1234)
>         MB_END_TAGS()
>
> Please explain if you think this it too difficult.

I have already said why this is not applicable to all users.

> Note: I refuse to believe that ORing flags into a .long is less complex.

I do, too. It is as as complex as using tags. So what?

Okuji

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Monday 04 December 2006 17:43, Hollis Blanchard wrote:
> It should be pretty clear that 32 bits are a finite number, and tags are
> unlimited. In fact it's worse than that, since the bit partitioning
> means we have far fewer available bits for any particular flag.

Tags are also finite, too, theoretically speaking. :p

If the number of bits is really a problem, it is even possible to make 
additional flags only when a bit in the original flags is set... Well, this 
is ugly, but this is the so-called tag structure as well, no?

Seriously, I really don't think the number of bits could be fatal. You were 
advocating removing the header itself, then why would you expect so much 
extension in the future?

> The bit numbering is also confusing, especially the partitioning of
> meanings (this is required, this is requested, this is arch-specific,
> this isn't).

I agree with this part. We can make it better.

> Finally, using flags for some things and tags for others is
> inconsistent.

I don't care. For OS developers, this inconsistency does not hurt them.

As I mentioned earlier, it is annoying to write tags by hand, while generating 
tags is as easy as parsing a fixed structure for programs. If you don't 
believe this, ask somebody else which looks easier:

.long   multiboot_header
.long   _start
.long   _edata
.long   _end
.long   multiboot_entry

or:

.long   HEADER_ADDRESS_TAG, 12, multiboot_header
.long   LOAD_START_ADDRESS_TAG, 12, _start
.long   LOAD_END_ADDRESS_TAG, 12, _edata
.long   BSS_END_ADDRESS_TAG, 12, _end
.long   ENTRY_ADDRESS_TAG, 12, multiboot_entry

>
> The extensibility argument alone is enough to seal it for me, especially
> since the code can be written in such an error-free manner, as I've
> demonstrated.

Is it a good spec which forces one to use sample code to be error-free? 

Okuji

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Tue, 2006-12-05 at 21:04 +0100, Yoshinori K. Okuji wrote:
> On Tuesday 05 December 2006 20:09, Hollis Blanchard wrote:
> > > I am all for something that is simple.  Initially it looked like
> > > Hollis' proposal was more complex, but IIRC he mentioned he wanted to
> > > work on making this easier to use.  Isn't this what he did?  Or did I
> > > misunderstand something?  If someone (Hollis in this case) thinks I am
> > > wrong and comes with a good argumentation, I am always willing to
> > > change my opinion.
> >
> > I already illustrated how easy it is:
> >         MB_HEADER()
> >         MB_START_TAGS()
> >         MB_LOADADDR(0x1234)
> >         MB_ENTRYADDR(0x1234)
> >         MB_END_TAGS()
> >
> > Please explain if you think this it too difficult.
> 
> I have already said why this is not applicable to all users.
> 
> > Note: I refuse to believe that ORing flags into a .long is less complex.
> 
> I do, too. It is as as complex as using tags. So what?

I thought we had two options: embedding tags, or ORing bits into an
embedded long. When I suggested embedding tags, you told me it was too
complicated so will cause developer errors. Have I misunderstood?

-Hollis

Re: multiboot2: using tags in the multiboot header

[Hollis Blanchard]

On Tue, 2006-12-05 at 21:23 +0100, Yoshinori K. Okuji wrote:
> 
> Is it a good spec which forces one to use sample code to be error-free? 

Please be serious.

I'm really not sure why you have such strong objections to this. We're
talking about a change that is MINOR in terms of code, but will make the
interface cleaner and more convenient for everybody. Please take a step
back and consider.

-Hollis

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Thursday 07 December 2006 23:39, Hollis Blanchard wrote:
> I thought we had two options: embedding tags, or ORing bits into an
> embedded long. When I suggested embedding tags, you told me it was too
> complicated so will cause developer errors. Have I misunderstood?

I meant that the complexity of using bitfields plus a fixed-size structure is 
identical to that of using tags. But I bet that it is more complicated to use 
tags _by hand_. For me, "complex" and "complicated" are quite different.

Besides how to make it look easier by predefined macros, please consider the 
spec itself. With bitfields and fixed-size fields, all you must remember is:

- What bits mean what

- How to order values passed to a boot loader

With tags, you need to remember:

- What tags mean what

- What tag size is expected to each tag

- What tags must be combined with a given tag

If you generate tags by programming, I don't think the use of tags is more 
complicated. It can be even easier for a parser. However, when specifying 
tags by hand, I cannot believe that it is as straightforward as using fields.

If you allow me to use a "big gun", I would tell you that most system 
programmers are used to fields, while they are not familar with writing tags.

Okuji

Re: multiboot2: using tags in the multiboot header

[Yoshinori K. Okuji]

On Friday 08 December 2006 00:07, Hollis Blanchard wrote:
> On Tue, 2006-12-05 at 21:23 +0100, Yoshinori K. Okuji wrote:
> > Is it a good spec which forces one to use sample code to be error-free?
>
> Please be serious.

I am perfectly serious here, although I like kidding.

> I'm really not sure why you have such strong objections to this. We're
> talking about a change that is MINOR in terms of code, but will make the
> interface cleaner and more convenient for everybody. Please take a step
> back and consider.

I have considered a lot. Still, considering. I am open to any new idea, but I 
haven't found your opinion convincing yet. I appreciate very much that you 
attempted to challenge this issue, though.

The reason why I object to your idea is that this is about a specification. It 
is a specification which will be used with no fundamental change for many 
years. Look at Multiboot Specification version 0.x. It has been used for 10 
years now without losing any backward compatibility. If we make a mistake, it 
would be a lot of burden for the users. Even if it is small for a given 
developer, the sum of efforts made by all developers is huge. Therefore, I 
need a good reason for every piece of it.

I said "if we make a mistake". This "we" includes myself. So I have spent some 
weeks only on this part before writing up the draft. Basically, you should 
assume that I have one or more reasons behind every part of the draft. So an 
attempt to change a part of it needs to beat reasons that I had in mind.

Okuji

Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Tue, 2006-12-12 at 23:08 +0100, Yoshinori K. Okuji wrote:
> On Thursday 07 December 2006 23:39, Hollis Blanchard wrote:
> > I thought we had two options: embedding tags, or ORing bits into an
> > embedded long. When I suggested embedding tags, you told me it was too
> > complicated so will cause developer errors. Have I misunderstood?
> 
> I meant that the complexity of using bitfields plus a fixed-size structure is 
> identical to that of using tags. But I bet that it is more complicated to use 
> tags _by hand_. For me, "complex" and "complicated" are quite different.
> 
> Besides how to make it look easier by predefined macros, please consider the 
> spec itself. With bitfields and fixed-size fields, all you must remember is:
> 
> - What bits mean what
> 
> - How to order values passed to a boot loader
> 
> With tags, you need to remember:
> 
> - What tags mean what
> 
> - What tag size is expected to each tag
> 
> - What tags must be combined with a given tag
> 
> If you generate tags by programming, I don't think the use of tags is more 
> complicated. It can be even easier for a parser. However, when specifying 
> tags by hand, I cannot believe that it is as straightforward as using fields.
> 
> If you allow me to use a "big gun", I would tell you that most system 
> programmers are used to fields, while they are not familar with writing tags.

I'm willing to go along with this, since I realized that only a tiny
number of people will need to use this flags (and that number does not
include me :). It seemed to work for GRUB Legacy, so I guess it can work
here too.

My loader code doesn't currently read either tags or flags, and since
most people don't need this functionality I plan to check it in without
that; it can be added later as needed.

-Hollis

Re: multiboot2: make multiboot header optional

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> On Mon, 2006-12-04 at 21:35 +0100, Marco Gerards wrote:
>> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>> 
>> > On Saturday 02 December 2006 17:18, Marco Gerards wrote:
>> >> What is the problem with typing?  I do not think this is really
>> >> complex?
>> >
>> > Weird. It was _you_ who pointed out that specifying tags would be
>> annoying on 
>> > the IRC...
>> 
>> I am all for something that is simple.  Initially it looked like
>> Hollis' proposal was more complex, but IIRC he mentioned he wanted to
>> work on making this easier to use.  Isn't this what he did?  Or did I
>> misunderstand something?  If someone (Hollis in this case) thinks I am
>> wrong and comes with a good argumentation, I am always willing to
>> change my opinion.
>
> I already illustrated how easy it is:
>         MB_HEADER()
>         MB_START_TAGS()
>         MB_LOADADDR(0x1234)
>         MB_ENTRYADDR(0x1234)
>         MB_END_TAGS()
>
> Please explain if you think this it too difficult.

You are missing my point, I said I agree with you.  Or am I
misunderstanding you?

--
Marco

Re: multiboot2: make multiboot header optional

[Yoshinori K. Okuji]

On Wednesday 13 December 2006 05:18, Hollis Blanchard wrote:
> I'm willing to go along with this, since I realized that only a tiny
> number of people will need to use this flags (and that number does not
> include me :). It seemed to work for GRUB Legacy, so I guess it can work
> here too.

Great. Finally we succeeded to agree (well, with some comprise?). :)

> My loader code doesn't currently read either tags or flags, and since
> most people don't need this functionality I plan to check it in without
> that; it can be added later as needed.

OK. So we can now proceed to the next question: whether it is a good idea to 
omit a header when it is not absolutely required (i.e. ELF and no flags). 
Honestly, I am quite neutral to this decision. I think it is a good 
convention to always put a kind of "magic" (e.g. think of the command "file" 
or libmagic), while the benefit of not writing anything special to Multiboot 
is also attractive.

What do others think about this?

Okuji