Oops, pressed the send button accidentally. The rest of the message follows :-)
On Wed, Feb 27, 2008 at 8:29 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote: > 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. 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
