Hello, Thank you for your answer.
On Tue, Feb 26, 2008 at 11:31 PM, Yoshinori K. Okuji <[EMAIL PROTECTED]> 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 > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
