From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GdKPX-0005mz-4e for mharc-grub-devel@gnu.org; Fri, 27 Oct 2006 01:37:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GdKPU-0005mg-Mj for grub-devel@gnu.org; Fri, 27 Oct 2006 01:37:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GdKPT-0005mS-8j for grub-devel@gnu.org; Fri, 27 Oct 2006 01:37:40 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GdKPT-0005mK-24 for grub-devel@gnu.org; Fri, 27 Oct 2006 01:37:39 -0400 Received: from [207.69.195.62] (helo=pop-altamira.atl.sa.earthlink.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GdKPT-00079H-2M for grub-devel@gnu.org; Fri, 27 Oct 2006 01:37:39 -0400 Received: from user-0vvdf2d.cable.mindspring.com ([63.246.188.77] helo=diesel.unsanctioned.org) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1GdKPQ-0002Uh-00 for grub-devel@gnu.org; Fri, 27 Oct 2006 01:37:36 -0400 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <20061027040907.GA2485@saphi> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <20061027040907.GA2485@saphi> Content-Type: text/plain Date: Fri, 27 Oct 2006 00:37:35 -0500 Message-Id: <1161927455.10997.2.camel@diesel> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit 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 05:37:41 -0000 On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote: > 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] What do you mean by UUID? I certainly would not like to see large magic numbers required in grub.cfg... > > 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. OK. In that case we're still keeping with the philosophy of only passing information to the kernel that it can't obtain itself. -Hollis