From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MNBhJ-0002pI-G6 for mharc-grub-devel@gnu.org; Sat, 04 Jul 2009 16:18:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNBhH-0002oy-0s for grub-devel@gnu.org; Sat, 04 Jul 2009 16:18:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNBhB-0002om-JM for grub-devel@gnu.org; Sat, 04 Jul 2009 16:18:53 -0400 Received: from [199.232.76.173] (port=44337 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNBhB-0002oj-EB for grub-devel@gnu.org; Sat, 04 Jul 2009 16:18:49 -0400 Received: from mx20.gnu.org ([199.232.41.8]:16662) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MNBhB-00081l-4H for grub-devel@gnu.org; Sat, 04 Jul 2009 16:18:49 -0400 Received: from aybabtu.com ([69.60.117.155]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MNBhA-0002aI-JQ for grub-devel@gnu.org; Sat, 04 Jul 2009 16:18:48 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1MNAd3-00068x-5c for grub-devel@gnu.org; Sat, 04 Jul 2009 21:10:29 +0200 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1MNBh8-0006jq-C2 for grub-devel@gnu.org; Sat, 04 Jul 2009 22:18:46 +0200 Date: Sat, 4 Jul 2009 22:18:46 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20090704201846.GD27480@thorin> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: Some ideas about new features of grub 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: Sat, 04 Jul 2009 20:18:55 -0000 On Thu, Jul 02, 2009 at 04:48:56PM +0800, Bean wrote: > Hi, > > Here are some of my ideas about the new features of grub. > > Move kernel to a module. > This make it possible to relocate the kernel. For example, we can use > it to move grub-pc to upper memory, and free conventional memory for > use by real mode os such as MS-DOS. grub can resides in memory even > after os take overs, and we can invoke it through interrupt hooks. It is already possible to relocate the kernel, in startup.S. Also, we can link the kernel in any address we want. Turning the kernel into a module sounds like killing rescue mode. Making modules a prerequisite for rescue mode to work is NOT a good idea. > LUA integration. > LUA is quite powerful, it's more suitable to do complicated task than > sh script. For example, we can use it to detect os at runtime, > implement simple commands, or draw the graphic menu. I don't mind LUA being supported, but I think it's unnecessarily big for the task GRUB is usually going to perform (the canonical example of that is in the default grub.cfg) in the majority of cases. I'd like to see *that* use case made more robust instead of switching to something else to obtain a flexibility we don't currently need. > Read/Write file system support > We can implement two kind of fs drivers. The boot time driver is > read-only, but after entering normal mode, we can optionally load > another driver for write support. This approach has been used by EFI. > For example, it has a default FAT driver, but you can also load an > extended FAT driver > later. I don't mind write filesystem support as long as its infrastructure is completely isolated from the kernel. That said, I think Marco objected to this before, so you'll have to talk with him about this. > Disk emulation. > Now that it has drivemap command, we can extended it to map hard disk > or cdrom image file, roughly equivalent to the memdisk of syslinux. Sounds like a killer feature, but would this actually work? Once whatever we're loading stops using the BIOS, it won't see the virtual drive anymore. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."