Re: Multiboot Specification

[Vegard Nossum]

Hello,

Thank you for your answer.

On Tue, Feb 26, 2008 at 11:31 PM, Yoshinori K. Okuji <address@hidden> wrote:
> On Sunday 24 February 2008 13:01, Vegard Nossum wrote:
>  > I have a question/comment regarding the Multiboot Specification. Since
>  > loaders need to read/load an object file anyway, wouldn't it be more
>  > appropriate to look for the multiboot header by looking up either a
>  > symbol name or a section name, rather than searching for a magic
>  > number within the first 8K bytes of the image?
>
>  No, because of the so-called a.out kludge. Since there are many (minor)
>  executable formats in this world, it is crucial to provide a
>  format-independent way in the Multiboot Speicification.
>
>
>  > This shouldn't be very difficult to implement for loaders, it would
>  > make loading safer (more reliable), and it would remove an otherwise
>  > artificial limitation. (It wouldn't have to be a requirement, but it
>  > could be a supplement to the magic number solution.)
>  >
>  > How would I proceed to suggest this change? :-)
>
>  Unless you have a convincing argument for the change, I wouldn't accept it.

My rationale is that it may be difficult to ensure that the header in
fact resides within the first 8 KB of the kernel image. Why was 8K
chosen? It seems like a completely arbitrary number. Even if the
multiboot header is explicitly placed close to the start of the
address space (by means of, say, link order or a linker script), is
this a guarantee that it will appear close to the start of the file?

Now, my knowledge of object file formats is rather limited, but I
don't think it's unreasonable to expect that an object file may have a
header of its own that is larger than 8K, thus pushing the multiboot
header and magic number outside the magic 8K boundary.

What I am trying to say is that there should be a fool-proof method of
getting your kernel image loaded and executed. A method which makes it
easy to rule out things like the wrong link order, etc. when your
image doesn't load.

>  All I can think of is about how to support IA-64. But my knowledge on IA-64 
> is
>  too limited, so I cannot make a good decision about it by myself.
>
>  Okuji
>
>
>
>
>  _______________________________________________
>  Grub-devel mailing list
>  address@hidden
>  http://lists.gnu.org/mailman/listinfo/grub-devel
>