[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiboot Specification
From: |
Vegard Nossum |
Subject: |
Re: Multiboot Specification |
Date: |
Wed, 27 Feb 2008 08:35:31 +0100 |
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