From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MMQRW-0002YK-Uo for mharc-grub-devel@gnu.org; Thu, 02 Jul 2009 13:51:30 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMQRV-0002Vv-FK for grub-devel@gnu.org; Thu, 02 Jul 2009 13:51:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMQRQ-0002Ma-M1 for grub-devel@gnu.org; Thu, 02 Jul 2009 13:51:28 -0400 Received: from [199.232.76.173] (port=41080 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMQRQ-0002M7-GH for grub-devel@gnu.org; Thu, 02 Jul 2009 13:51:24 -0400 Received: from c60.cesmail.net ([216.154.195.49]:36041) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MMQRP-0007D0-TY for grub-devel@gnu.org; Thu, 02 Jul 2009 13:51:24 -0400 Received: from unknown (HELO smtprelay1.cesmail.net) ([192.168.1.111]) by c60.cesmail.net with ESMTP; 02 Jul 2009 13:51:16 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay1.cesmail.net (Postfix) with ESMTPSA id 6B8C234C6D for ; Thu, 2 Jul 2009 13:51:15 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: Content-Type: text/plain Date: Thu, 02 Jul 2009 13:51:14 -0400 Message-Id: <1246557074.30158.20.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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: Thu, 02 Jul 2009 17:51:29 -0000 On Thu, 2009-07-02 at 16:48 +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. I don't care about MS DOS. Other OSes should not need GRUB. If you want GRUB to be a supervisor or a microkernel, it's better that GRUB loads them instead of incorporating their functionality. The only reason for GRUB to _be_ a supervisor or a microkernel would be to implement some kind of TPM, and I don't think we should spend development effort on that unless were can be sure that it won't be used against our users. > 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. Yes, I think LUA improvements should continue. We may switch to a LUA implementation of grub.cfg at some point. > 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 think it's pure featuritis. There is no reason for a bootloader to write to filesystems except to store it's state, which is already implemented. What would GRUB write? Implementing and maintaining full featured drivers would take a lot of effort. I'd rather see someone implement UUIDs for all filesystems. > 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. Hard drives and CD-ROMs are usually large and would take a lot of space in memory that would need to remain allocated. I think we need a strong case to start that effort. I'd rather see an effort to support CD-ROM and other ATAPI devices without disrupting BIOS access to the hard drives and floppies. We also need AHCI support. -- Regards, Pavel Roskin