grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Split of the normal mode


From: Bean
Subject: Re: [PATCH] Split of the normal mode
Date: Sun, 29 Mar 2009 22:30:48 +0800

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]