From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GkSzA-0004Qf-VG for mharc-grub-devel@gnu.org; Wed, 15 Nov 2006 17:12:00 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GkSz9-0004OX-DA for grub-devel@gnu.org; Wed, 15 Nov 2006 17:11:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GkSz7-0004Mj-MC for grub-devel@gnu.org; Wed, 15 Nov 2006 17:11:58 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GkSz7-0004Mf-H7 for grub-devel@gnu.org; Wed, 15 Nov 2006 17:11:57 -0500 Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GkSUh-0001OE-Lx for grub-devel@gnu.org; Wed, 15 Nov 2006 16:40:31 -0500 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by mx20.gnu.org with esmtp (Exim 4.52) id 1GkSUf-0000CB-ST for grub-devel@gnu.org; Wed, 15 Nov 2006 16:40:30 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAFLdgwD005679 for ; Wed, 15 Nov 2006 16:39:42 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAFLdQ8v090508 for ; Wed, 15 Nov 2006 16:39:36 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAFLdPsq032751 for ; Wed, 15 Nov 2006 16:39:25 -0500 Received: from [9.53.41.42] (basalt.austin.ibm.com [9.53.41.42]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAFLdPmr032722 for ; Wed, 15 Nov 2006 16:39:25 -0500 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <200611152142.16440.okuji@enbug.org> References: <1163545104.12931.49.camel@basalt> <87psbphyu3.fsf@night.trouble.net> <1163616145.8873.35.camel@basalt> <200611152142.16440.okuji@enbug.org> Content-Type: text/plain Date: Wed, 15 Nov 2006 15:39:20 -0600 Message-Id: <1163626760.8873.128.camel@basalt> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: multiboot2: make multiboot header optional X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 22:11:59 -0000 On Wed, 2006-11-15 at 22:42 +0200, Yoshinori K. Okuji wrote: > On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote: > > > If the operating system kernel is stupid enough to require as special > > > video mode the user should be aware of that and setup the bootloader > > > so that it is in that mode before the kernel is started. > > > > The only information in the multiboot header is a) the load addresses > > for a.out and "other" formats, and b) the VGA info. > > > > We could certainly drop the VGA info. > > No. The problem is that a kernel cannot initialize VESA in protected mode in > some BIOSes. If you need more info, please dig into the archive of bug-grub. OK, that is unfortunate. > > I don't think it would be a big deal to drop a.out as well; I don't know > > of any modern OS that uses these, and anyways kernel builds are special. > > However (and I don't know how reasonable this is), Mac OS X's toolchain > > will build only Mach-O binaries, so one would be unable to build a > > kernel that GRUB could load. We could require a Mach-O loader in that > > case, but I will admit that the "a.out hack" multiboot header fields > > simplify this problem. > > Never drop the a.out kludge. This flexibility is one of the advantages in > Multiboot. Note that GRUB itself uses this feature. I still would like an improvement in the kernel->GRUB communication. What about reusing the tags structure? For example: multiboot_header: .long MAGIC .long MULTIBOOT_TAG_START [...] .long MULTIBOOT_TAG_LOADADDR ; .long 12 ; .long _start .long MULTIBOOT_TAG_ENTRYADDR ; .long 12 ; .long main .long MULTIBOOT_TAG_END ; .long 8 etc? A cpp macro or two could make that a little more convenient. The fact that the START tag requires the number of tags and number of bytes is inconvenient here. Do we really need that? Why not just: while (tag->key != MULTIBOOT_TAG_END) process_tag(tag); -Hollis