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: Tue, 31 Mar 2009 00:42:53 +0900
User-agent: KMail/1.9.10

On Monday 30 March 2009 00:17:59 Bean wrote:
> >> 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?
>
> For example, something the boot modules can't detect boot partition
> properly, such as some raid/lvm, etc. We might want to use uuid or
> label to identify the partition. Then, there is a problem, how to
> store the uuid value for the boot modules to use.
>
> Previously, I have thought of embedding a envblk in the kernel, then
> modules can read variables at startup. But this method is quite
> clumsy, and it needs to reserve valuable kernel size. Using a boot
> script seems much flexible to me. Besides, it doesn't require
> additional kernel space. The kernel can already parse commands in
> rescue shell, I just reuse this function to run the boot script.

I understand. Actually, GRUB Legacy has the same feature, named "preset menu", 
with which you can embed a config file in stage2. This feature is not used 
very much, because it requires recompilation in GRUB Legacy.

> > Do you want to use GRUB without the scripting engine?
>
> The point is to support alternative script engine. Actually, I'm
> thinking about integrating clisp into grub2. But some people may not
> know about it, so they can still use the old bash engine.

Sounds nice. :)

But I still think that your patch splits into too many. If you split normal 
mode into:

- a script module (sh.mod?)
- a text menu module (menu.mod?)
- the rest (normal.mod)

then, that's fine.

Regards,
Okuji




reply via email to

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