From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lnumj-00025z-RP for mharc-grub-devel@gnu.org; Sun, 29 Mar 2009 09:10:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lnumh-00025n-Pl for grub-devel@gnu.org; Sun, 29 Mar 2009 09:10:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lnumh-00025Z-8T for grub-devel@gnu.org; Sun, 29 Mar 2009 09:10:43 -0400 Received: from [199.232.76.173] (port=53301 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lnumh-00025U-2h for grub-devel@gnu.org; Sun, 29 Mar 2009 09:10:43 -0400 Received: from mail.nexedi.com ([91.121.25.85]:41953 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lnumg-0004iy-Mm for grub-devel@gnu.org; Sun, 29 Mar 2009 09:10:42 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id A26853D9F7 for ; Sun, 29 Mar 2009 15:10:40 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 29 Mar 2009 22:10:34 +0900 User-Agent: KMail/1.9.10 References: <200903292051.07210.okuji@enbug.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903292210.34870.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] Split of the normal mode 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: Sun, 29 Mar 2009 13:10:44 -0000 On Sunday 29 March 2009 21:09:05 Bean wrote: > Hi, > > Some of my consideration about splitting of normal mode. > > 1, In some environment, we have size limit of the boot image. > Normal.mod is too big, and rescue mode has too little functionality. > Using the split method, we could combine modules in anyway we wanted. In my opinion, you are postponing the decision to the runtime too much. If you have N modules, you have N! combinations, but we don't need to support that many in reality. I bet that you know which portions of the normal mode you would like to select for your own need. Surely, others might have different needs, but the number of modules you added looks overkill to me. > 2, Speaking of linux, it's actually doing the same thing. The kernel > is in vmlinuz, while the initialization script is in initrd.img. We > don't want the user to enter those commands manually, a default > boot.cfg should be used by grub-mkimage. Mmh, I hardly agree on this. The purpose of initrd.img is, although it could be abused, to bootstrap an OS environment for further work, which is analogous to core.img in GRUB. For the rest of the work, ifplugd, udev, etc. take care of loading appropriate modules on demand. > 3. Currently, the structure of normal.mod just mix things together to > a point that make modification difficult, if not impossible. For > example, the current bash script engine is not quite suitable for gui > interaction. With the split mode, we could develop a new parser > without interfere with existing function. I prefer that you replace the existing code with a better implementation in this case. From my point of view, fancy menu support is a key feature in GRUB, thus if the current engine is not good enough, we need to improve it rather than to provide an alternative. Regards, Okuji