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 23:54:48 +0900
User-agent: KMail/1.9.10

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?

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

Regards,
Okuji




reply via email to

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