Re: [PATCH] Split of the normal mode

[Bean]

On Sun, Mar 29, 2009 at 10:54 PM, Yoshinori K. Okuji <address@hidden> wrote:
> 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?
>

For example, something the boot modules can't detect boot partition
properly, such as some raid/lvm, etc. We might want to use uuid or
label to identify the partition. Then, there is a problem, how to
store the uuid value for the boot modules to use.

Previously, I have thought of embedding a envblk in the kernel, then
modules can read variables at startup. But this method is quite
clumsy, and it needs to reserve valuable kernel size. Using a boot
script seems much flexible to me. Besides, it doesn't require
additional kernel space. The kernel can already parse commands in
rescue shell, I just reuse this function to run the boot script.

>> >> >> 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?

The point is to support alternative script engine. Actually, I'm
thinking about integrating clisp into grub2. But some people may not
know about it, so they can still use the old bash engine.

-- 
Bean