Idea: elimination of the normal mode

Idea: elimination of the normal mode

[Bean]

Hi,

First of all, one of the annoying thing about normal mode is that we
have two sets of command, one for rescue mode, one for normal mode.
Take a closer look at them, they're very similar, expect for the
argument options. If we move the option analyzer from normal.mod to
kernel, then we can have one unified set of commands.

About the duplicated commands, we can create a module minicmd to
include the most basic command, and allow for overwrite. So, there is
a minimal ls command in minicmd which would be embedded in the kernel,
but if we need the extra feature, we can load the external ls module.

After resolving the problem of two command sets, I start to wonder if
normal mode is necessary at all. In fact, its function can be
separated into the following parts:

Interface:
We can support multiple interface. The kernel's interface is a console
mode tty interface. Normal mode is the menu interface. But this is not
the only option. For example, we can have a simple chooser. The
different boot option is output line by line, and we can enter the
number to choose them. This interface is very useful in terminal that
doesn't support absulote cursor or graphic character. We can also have
graphic interface, where the layout is completely decided by the
module, not limited by interface of text mode.

Script engine:
We can also support multiple script engines. In kernel, there is just
the basic line scanner. The current normal mode engine is bash-like
parser. We can add other engines in the future, csh-like or so.

Each engine would have a separate configuration file. The default is a
line by line command list used by the kernel scanner. This look some
like preset menu of grub legacy. From this file, we load modules that
would bring us to normal environment. For example, it may look
something like this:

set rdir=/boot/grub
search -s ${rdir}/grub.cfg
insmod bash
insmod text-menu

This file would be embedded in the kernel, as root is yet to be
defined. From this file, we set the root environment and load extra
module. This would eliminate the need for static grub_prefix.

-- 
Bean

Re: Idea: elimination of the normal mode

[Robert Millan]

On Sat, Jul 05, 2008 at 10:46:56AM +0800, Bean wrote:
> If we move the option analyzer from normal.mod to
> kernel, then we can have one unified set of commands.

How much space could this represent?

> About the duplicated commands, we can create a module minicmd to
> include the most basic command

Then we can't have a rescue shell before heap is initialised and minicmd
is loaded.  Should we be concerned about this?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: Idea: elimination of the normal mode

[Stefan Reinauer]

Robert Millan wrote:
>> About the duplicated commands, we can create a module minicmd to
>> include the most basic command
>>     
>
> Then we can't have a rescue shell before heap is initialised and minicmd
> is loaded.  Should we be concerned about this?
>   
What would one use that rescue shell for?



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info@coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Re: Idea: elimination of the normal mode

[Vesa Jääskeläinen]

Stefan Reinauer wrote:
> Robert Millan wrote:
>>> About the duplicated commands, we can create a module minicmd to
>>> include the most basic command
>>>     
>> Then we can't have a rescue shell before heap is initialised and minicmd
>> is loaded.  Should we be concerned about this?
>>   
> What would one use that rescue shell for?

Idea of the rescue shell is load other modules in case grub itself 
cannot find them. It provides thin layer of tools so user is able to 
find them.

Personally I would like to keep this functionality in core.img.

Re: Idea: elimination of the normal mode

[Bean]

On Sat, Jul 5, 2008 at 8:15 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Sat, Jul 05, 2008 at 10:46:56AM +0800, Bean wrote:
>> If we move the option analyzer from normal.mod to
>> kernel, then we can have one unified set of commands.
>
> How much space could this represent?

It won't take much, the code is basically inside normal/arg.c.

>
>> About the duplicated commands, we can create a module minicmd to
>> include the most basic command
>
> Then we can't have a rescue shell before heap is initialised and minicmd
> is loaded.  Should we be concerned about this?

The rescue shell is still there. It's part of the line by line command scanner.

-- 
Bean

Re: Idea: elimination of the normal mode

[Bean]

On Sun, Jul 6, 2008 at 1:32 AM, Bean <bean123ch@gmail.com> wrote:
>>> About the duplicated commands, we can create a module minicmd to
>>> include the most basic command
>>
>> Then we can't have a rescue shell before heap is initialised and minicmd
>> is loaded.  Should we be concerned about this?
>
> The rescue shell is still there. It's part of the line by line command scanner.

Hi,

Here is another way to look at rescue/normal mode.

rescue mode:
basic console interface + line scanner

normal mode:
advanced console interface (history, completion) + script parser
text menu interface + script parser

-- 
Bean

Re: Idea: elimination of the normal mode

[Stefan Reinauer]

Vesa Jääskeläinen wrote:
> Stefan Reinauer wrote:
>> Robert Millan wrote:
>>>> About the duplicated commands, we can create a module minicmd to
>>>> include the most basic command
>>>>     
>>> Then we can't have a rescue shell before heap is initialised and
>>> minicmd
>>> is loaded.  Should we be concerned about this?
>>>   
>> What would one use that rescue shell for?
>
> Idea of the rescue shell is load other modules in case grub itself
> cannot find them. It provides thin layer of tools so user is able to
> find them.
>
> Personally I would like to keep this functionality in core.img. 
So, how is the "rescue shell" different that "grub itself". Why would it
find modules that "grub itself" does not find?

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info@coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Re: Idea: elimination of the normal mode

[Vesa Jääskeläinen]

Stefan Reinauer wrote:
> Vesa Jääskeläinen wrote:
>> Idea of the rescue shell is load other modules in case grub itself
>> cannot find them. It provides thin layer of tools so user is able to
>> find them.
>>
>> Personally I would like to keep this functionality in core.img. 
> So, how is the "rescue shell" different that "grub itself". Why would it
> find modules that "grub itself" does not find?

User can use ls and insmod commands to load those modules from disk. 
Most common problem with GRUB legacy is that it just prints GRUB on 
screen. This will kinda remove that problem as user still has a way to 
boot his system with some keypresses.

Re: Idea: elimination of the normal mode

[Stefan Reinauer]

Vesa Jääskeläinen wrote:
> Stefan Reinauer wrote:
>> Vesa Jääskeläinen wrote:
>>> Idea of the rescue shell is load other modules in case grub itself
>>> cannot find them. It provides thin layer of tools so user is able to
>>> find them.
>>>
>>> Personally I would like to keep this functionality in core.img. 
>> So, how is the "rescue shell" different that "grub itself". Why would it
>> find modules that "grub itself" does not find?
>
> User can use ls and insmod commands to load those modules from disk.
> Most common problem with GRUB legacy is that it just prints GRUB on
> screen. This will kinda remove that problem as user still has a way to
> boot his system with some keypresses.
So the rescue shell has filesystems and a shell? Is the "advanced
console interface" so huge that it can't live with the shell and the
filesystems in the rescue shell?


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info@coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Re: Idea: elimination of the normal mode

[Vesa Jääskeläinen]

Stefan Reinauer wrote:
> Vesa Jääskeläinen wrote:
>> Stefan Reinauer wrote:
>>> Vesa Jääskeläinen wrote:
>>>> Idea of the rescue shell is load other modules in case grub itself
>>>> cannot find them. It provides thin layer of tools so user is able to
>>>> find them.
>>>>
>>>> Personally I would like to keep this functionality in core.img. 
>>> So, how is the "rescue shell" different that "grub itself". Why would it
>>> find modules that "grub itself" does not find?
>> User can use ls and insmod commands to load those modules from disk.
>> Most common problem with GRUB legacy is that it just prints GRUB on
>> screen. This will kinda remove that problem as user still has a way to
>> boot his system with some keypresses.
> So the rescue shell has filesystems and a shell? Is the "advanced
> console interface" so huge that it can't live with the shell and the
> filesystems in the rescue shell?

It has anything what core provides. If by this you get core smaller then 
I am all for it. If it makes it larger then I would propose to find free 
space from somewhere else. Core.img just have to be standalone 
application so user can do recovery if something gets wrong in 
installation or something else.

I do not know how well grub scripting is integrated to normal mode so 
check that out first.

Re: Idea: elimination of the normal mode

[Bean]

On Sun, Jul 6, 2008 at 2:10 AM, Vesa Jääskeläinen <chaac@nic.fi> wrote:
> It has anything what core provides. If by this you get core smaller then I
> am all for it. If it makes it larger then I would propose to find free space
> from somewhere else. Core.img just have to be standalone application so user
> can do recovery if something gets wrong in installation or something else.
>
> I do not know how well grub scripting is integrated to normal mode so check
> that out first.

Hi,

With my suggestion, core.img would contain:

minicmd + basic console interface + line scanner + fs modules

It would be slightly bigger because we also add the option analyzer.
But it may also reduce size due to better function separation.

the line scanner would read a config file, which instruct extra
modules to be loaded For example, to archive the same function of
normal mode, we need:

advanced console interface + text menu interface + script engine.

Some advantage of this scheme:

1, One set of command. Now, if we want to use command like search, we
must also include normal.mod, whose purpose is just to provide the
option analyzer.

2, The separation of interface and script engine.
Interface deal with interaction with user, like draw the menu, choose
an menu item, edit a string, etc. Script engine is responsible for the
interpretation of commands. These two parts are independent, we
shouldn't bundle them into a single normal.mod.This would make modules
like graphic interface more difficult to implement.

-- 
Bean

Re: Idea: elimination of the normal mode

[Vesa Jääskeläinen]

Bean wrote:
> On Sun, Jul 6, 2008 at 2:10 AM, Vesa Jääskeläinen <chaac@nic.fi> wrote:
>> It has anything what core provides. If by this you get core smaller then I
>> am all for it. If it makes it larger then I would propose to find free space
>> from somewhere else. Core.img just have to be standalone application so user
>> can do recovery if something gets wrong in installation or something else.
>>
>> I do not know how well grub scripting is integrated to normal mode so check
>> that out first.
> 
> With my suggestion, core.img would contain:
> 
> minicmd + basic console interface + line scanner + fs modules
> 
> It would be slightly bigger because we also add the option analyzer.
> But it may also reduce size due to better function separation.

It total size is smaller I do not care. If not, then I would pass it. I 
still like the idea to separate rescue mode from "normal" shell mode. 
This gives user an idea that grub has failed to load more of itself.

I think Robert has from time to time complained that core.img gets too 
big sometimes to be embedded especially on raid configurations. So 
increasing size with this does not sound good on my ears.

> the line scanner would read a config file, which instruct extra
> modules to be loaded For example, to archive the same function of
> normal mode, we need:
> 
> advanced console interface + text menu interface + script engine.
> 
> Some advantage of this scheme:
> 
> 1, One set of command. Now, if we want to use command like search, we
> must also include normal.mod, whose purpose is just to provide the
> option analyzer.

Rescue is supposed to be minimal anyway.

> 2, The separation of interface and script engine.
> Interface deal with interaction with user, like draw the menu, choose
> an menu item, edit a string, etc. Script engine is responsible for the
> interpretation of commands. These two parts are independent, we
> shouldn't bundle them into a single normal.mod.This would make modules
> like graphic interface more difficult to implement.

Well interaction between textual menu, graphical menu and shell 
interface will be studied anyway by Colin during his GSoC activities so 
lets wait what we get from there before jumping too far.