From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GdIzh-0006zj-8E for mharc-grub-devel@gnu.org; Fri, 27 Oct 2006 00:06:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GdIze-0006x6-7j for grub-devel@gnu.org; Fri, 27 Oct 2006 00:06:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GdIzc-0006sY-6R for grub-devel@gnu.org; Fri, 27 Oct 2006 00:06:53 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GdIzc-0006rw-0d for grub-devel@gnu.org; Fri, 27 Oct 2006 00:06:52 -0400 Received: from [212.27.42.27] (helo=smtp1-g19.free.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GdIzb-0004Ey-Ki for grub-devel@gnu.org; Fri, 27 Oct 2006 00:06:51 -0400 Received: from saphi (boi78-1-82-232-198-173.fbx.proxad.net [82.232.198.173]) by smtp1-g19.free.fr (Postfix) with ESMTP id 997BDC61 for ; Fri, 27 Oct 2006 06:06:50 +0200 (CEST) Received: from gingold by saphi with local (Exim 3.36 #1 (Debian)) id 1GdJ1n-0000ea-00 for ; Fri, 27 Oct 2006 06:09:07 +0200 Date: Fri, 27 Oct 2006 06:09:07 +0200 To: The development of GRUB 2 Message-ID: <20061027040907.GA2485@saphi> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1161892715.17811.33.camel@basalt.austin.ibm.com> User-Agent: Mutt/1.5.6+20040907i From: Tristan Gingold Subject: Re: some multiboot2 comments 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: Fri, 27 Oct 2006 04:06:54 -0000 On Thu, Oct 26, 2006 at 02:58:35PM -0500, Hollis Blanchard wrote: > http://grub.enbug.org/MultibootDraft > > I'm looking at implementing this now. > > Module: > Because of the 'length' field in the tag header, the 'reserved' field > isn't actually needed. The 'length' field makes every one of these tag > structures inherently variably sized. Any data added later to this tag > will be skipped over by the reader. Yes. BTW, why not adding a type field for module tag. The type (which should be an UUID IMHO) should indicate the type of the module. One usage could be for Xen. On Xen you can load 3 modules: the linux kernel, the linux ramdisk and an ACM configuration. Xen relies on order and on some magic checks to find the module type. The command syntax could be: module [-type TYPE] file [cmdline] > Memory Map: > I'm not sure if we need this. The OS can get this information from > firmware (e.g. BIOS e820 map or Open Firmware) as easily as we can, > right? In general, I don't think we should convert firmware information > into the multiboot structure. Some platform may need it. On EFI the OS can't get the memmap from EFI because it is too late. Tristan.