Re: Multiboot Specification

[Vegard Nossum]

Oops, pressed the send button accidentally. The rest of the message follows :-)

On Wed, Feb 27, 2008 at 8:29 AM, Vegard Nossum <address@hidden> wrote:
> 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.

So how about removing the 8K limit and simply search the whole image?
What is the purpose of this limit?

Thanks.


Kind regards,
Vegard Nossum