Re: Idea: elimination of the normal mode (revised version)

[Bean]

On Fri, Jul 18, 2008 at 2:58 AM, Pavel Roskin <address@hidden> wrote:
> On Thu, 2008-07-17 at 11:24 +0800, Bean wrote:
>
>> Any comment for this idea ?
>
> Maybe you could describe was it will give us and what the drawbacks may
> be?  It's hard to comment on the implementation ideas without seeing the
> bigger picture.

Hi,

In the previous thread "Idea: elimination of the normal mode", I have
listed some of the reasons. Here are the advantages of this scheme:

1. One command set

One of the annoying thing of current implementation is that it has two
command set, rescue command and normal command. Some command that can
be called in both rescue mode and normal mode have two modules, like
linux.mod and _linux.mod. What's more, normal mode command depend on
normal.mod, so if we want to include search.mod in grub-mkimage,
normal.mod will be included as well, which make the image quite big.

But if we take a look at the two command sets, one major different is
that rescue command pass argument directly to command, while normal
mode command parse it first to get options, then pass it and the rest
of argument to the command.

Therefore, normal command is essentially rescue command plus argument
parser, we can unify them into one command set. Also, normal command
would only depend on argument parser, which is a lot smaller than
normal.mod.

2. Separation of script engine and interface

Another thing about normal.mod is that it bundles script engine and
interface handler together, which makes it more difficult to extend
its function. We can split the two components:

Script engine is responsible for parsing config file, getting menu
list, and execution of commands, etc.

Interface is responsible for drawing the menu, handling user input, etc.

These two component are independent. For example, when interface
module want to know the menu list to draw on screen, it asks script
engine for it, instead of calling a fixed function.

Rescue mode and normal mode uses different script engine and interface.

Rescue mode:

The script engine is a basic line based scanner, which splits the
command line using space.

The interface is the rescue shell, which accept user input, then calls
the script engine to execute it.

Normal mode:

The script engine is a bash-like parser, it can return menu list as well.

The console interface is a little advanced than the rescue shell, it
has auto completion and history.

The menu interface is the normal menu, it calls script engine to get
the menu list, and uses it to execute commands when user select a menu
item.

Other possible interface:

simple menu:

Some terminal doesn't support arbitrary cursor position, so we could
implement a simple menu interface where the available items are
displayed line by line, with a number indicator. User can choose them
using the indicator.

graphic menu:

It's difficult to merge graphic menu with text menu, as graphic mode
provide more features. Graphic menu can use a style config file to
control the drawing of windows, while in text menu, there is really
not much option available, so we just hard-coded the drawing in the
module.

3. Highly configurable

After we seperate the above function from normal.mod, we have a highly
configurable system. We can select the component we wanted in
grub-mkimage. What's more, as there is a basic line based scanner, we
can use it to setup the initial environment, like locating root using
uuid, setup parameter for serial console, and so on. This feature
looks like the preset menu in grub legacy.

It also works well in embedded environment. For example, if we want to
use grub2 to boot directly, there is no need to include the interface
components. Also, if we have included advanced console in core.img,
there is no need for basic console.

-- 
Bean