From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MWnKQ-0003VP-W4 for mharc-grub-devel@gnu.org; Fri, 31 Jul 2009 04:19:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWnKO-0003RK-88 for grub-devel@gnu.org; Fri, 31 Jul 2009 04:19:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWnKI-0003K8-VD for grub-devel@gnu.org; Fri, 31 Jul 2009 04:18:59 -0400 Received: from [199.232.76.173] (port=45369 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWnKI-0003K0-IA for grub-devel@gnu.org; Fri, 31 Jul 2009 04:18:54 -0400 Received: from mx20.gnu.org ([199.232.41.8]:34450) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MWnKI-000054-6b for grub-devel@gnu.org; Fri, 31 Jul 2009 04:18:54 -0400 Received: from smtp-vbr8.xs4all.nl ([194.109.24.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MWnKH-0004cQ-1O for grub-devel@gnu.org; Fri, 31 Jul 2009 04:18:53 -0400 Received: from marco (249-174.surfsnel.dsl.internl.net [145.99.174.249]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6V8Ipuk052691 for ; Fri, 31 Jul 2009 10:18:51 +0200 (CEST) (envelope-from mgerards@xs4all.nl) From: Marco Gerards To: The development of GRUB 2 References: <1246557074.30158.20.camel@mj> Mail-Copies-To: mgerards@xs4all.nl Date: Fri, 31 Jul 2009 10:18:50 +0200 In-Reply-To: <1246557074.30158.20.camel@mj> (Pavel Roskin's message of "Thu, 02 Jul 2009 13:51:14 -0400") Message-ID: <87ws5puuxh.fsf@xs4all.nl> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner X-Detected-Operating-System: by mx20.gnu.org: FreeBSD 4.6-4.9 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: Fri, 31 Jul 2009 08:19:00 -0000 Pavel Roskin writes: > 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. Please, don't. I never had objections against lua, but lua should not silently take over. >> 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. Agreed. >> 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. Right. Although I do not mind if a separate module is added for this. Given that the person who adds it will maintain it properly. -- Marco