On Sun, Mar 29, 2009 at 10:20 PM, Yoshinori K. Okuji <ok...@enbug.org> wrote: >> >> 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.
But how to store the parameters ? Boot media is not available, so we can't read file, and we can't embed them in code. > >> >> 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? The script engine is quite large, if we put them all in normal.mod, it'd be messy. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
