On Sunday 29 March 2009 22:59:53 Bean wrote: > On Sun, Mar 29, 2009 at 9:10 PM, Yoshinori K. Okuji <ok...@enbug.org> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
