From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LnvsX-00076y-Kv for mharc-grub-devel@gnu.org; Sun, 29 Mar 2009 10:20:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LnvsV-00076G-TU for grub-devel@gnu.org; Sun, 29 Mar 2009 10:20:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LnvsV-00075q-5s for grub-devel@gnu.org; Sun, 29 Mar 2009 10:20:47 -0400 Received: from [199.232.76.173] (port=42333 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnvsV-00075j-0j for grub-devel@gnu.org; Sun, 29 Mar 2009 10:20:47 -0400 Received: from mail.nexedi.com ([91.121.25.85]:35787 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LnvsU-0004Yp-AL for grub-devel@gnu.org; Sun, 29 Mar 2009 10:20:46 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id B85083D9F8 for ; Sun, 29 Mar 2009 16:20:44 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 29 Mar 2009 23:20:38 +0900 User-Agent: KMail/1.9.10 References: <200903292210.34870.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: <200903292320.38804.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 14:20:48 -0000 On Sunday 29 March 2009 22:59:53 Bean wrote: > On Sun, Mar 29, 2009 at 9:10 PM, Yoshinori K. Okuji wrote: > > 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. > > Actually, there is still only one normal configuration. But others > could be useful in some situation. We could hide the details from > normal user, but they can do such configuration if required. My basic attitude is "making it only if it is used in pracice". If your goal is virtual, I don't want to accept it. > > >> 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. > > Sometime we need to setup the environment before it can access boot > media. For example, locating the boot partition using label/uuid, > setting the network address, etc, this is where boot.cfg can be quite > useful. If you use a label, label support should be loaded automatically. If you use an uuid, uuid support should be loaded automatically. If you set up a network, network support should be loaded automatically. So I see no reason to stop automatic loading. > >> 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. > > If I were to fix this problem, I'd separate parser and reader code > anyway. In fact, colin already separate the menu viewer code. The > problem is to still keep them in a single normal.mod, or to move them > to logical independent modules. I see no problem with the later. Views can be separete. I don't deny this. But the scripting engine itself should stay in normal mode. What is wrong with this? Regards, Okuji