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: Yoshinori K. Okuji
Subject: Re: [PATCH] Split of the normal mode
Date: Sun, 29 Mar 2009 22:10:34 +0900
User-agent: KMail/1.9.10

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.

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

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

Regards,
Okuji




reply via email to

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