Re: [PATCH] Split of the normal mode

["Yoshinori K. Okuji" <okuji@enbug.org>]

On Sunday 29 March 2009 22:59:53 Bean wrote:
> On Sun, Mar 29, 2009 at 9:10 PM, Yoshinori K. Okuji <okuji@enbug.org> 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.

My basic attitude is "making it only if it is used in pracice". If your goal 
is virtual, I don't want to accept it.

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

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

Regards,
Okuji