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 21:59:53 +0800

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

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

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

-- 
Bean




reply via email to

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