On Sunday 29 March 2009 23:30:48 Bean wrote: > > 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.
Could you be more specific? What case are you talking about? > >> >> 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. Do you want to use GRUB without the scripting engine? Regards, Okuji _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel