From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JI9Xl-00035m-VE for mharc-grub-devel@gnu.org; Thu, 24 Jan 2008 16:23:29 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JI9Xj-000357-QX for grub-devel@gnu.org; Thu, 24 Jan 2008 16:23:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JI9Xi-00034u-F5 for grub-devel@gnu.org; Thu, 24 Jan 2008 16:23:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JI9Xi-00034r-AH for grub-devel@gnu.org; Thu, 24 Jan 2008 16:23:26 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JI9Xh-0004Th-WF for grub-devel@gnu.org; Thu, 24 Jan 2008 16:23:26 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 80E123EB23 for ; Thu, 24 Jan 2008 22:29:32 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Thu, 24 Jan 2008 22:23:12 +0100 User-Agent: KMail/1.9.4 References: <20080122135757.GA11484@thorin> <20080124113244.GA2249@thorin> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801242223.13091.okuji@enbug.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: [PATCH] memdisk plus lnxboot extension 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: Thu, 24 Jan 2008 21:23:28 -0000 On Thursday 24 January 2008 12:49, Bean wrote: > On Jan 24, 2008 7:32 PM, Robert Millan wrote: > > Sorry, my question was confusing; what I meant is, where is it located > > when core.img is started. But Just checked in our Linux loader, and it > > seems to be at a very high address. > > > > However, a very high address doesn't garantee that it won't be > > overwritten by lzo decompression, just makes it less likely. > > > > Overall, this is why I don't like having to stick to a particular boot > > mechanism. If our goal is overcome the size limit in memdisk, why not > > design the boot mechanism ourselves? > > I'm not familiar with multiboot spec, does it support arbitrary kernel size > ? Why not? ;) The theoretical limit is that defined by an architecture, such as 4GB in 32-bit addressing. If you find a stronger limit, it must be an implementation limit. Okuji