Re: on splitting modules

[Bean]

On Mon, Apr 6, 2009 at 1:55 AM, Yoshinori K. Okuji <address@hidden> wrote:
> Hello,
>
> I have written an article on the wiki right now:
>
> http://grub.enbug.org/OnSplittingModules
>
> This article is based on our discussion on the IRC. I think the disagreement
> between Bean and me derived from that I didn't know his ultimate goal, and
> actually I investigated the same idea as him a long time ago.
>
> Now, I am very excited with his work, and I hope he will succeed.

Hi,

Right, my goal is to provide smooth transition from rescue mode to
normal mode, you can fine tune the process using modules.

1, Command
Now commands are unified, no distinction between rescue and normal
mode. Commands has a priority value. For example, we can have two ls
commands, one in kernel, the other in ls.mod. After normal.mod starts,
command.lst is loaded so that it will choose the highest priority
command automatically.

Basic command don't use extra feature, their support is in the kernel.
Extended command need to parse argument, for example, to translate
--file to grub_arg_list structure. Extended command depends on
extcmd.mod.
Occasionally, command needs to use extra function. They can depend on
misc.mod. misc.mod can be viewed as an extension to kern/misc.c, which
provides common used function not suitable to be placed in kernel.

2. Reader
Kernel contains rescue reader. After switching to normal reader, we
has command history and auto completion.

3. Parser
Kernel contains rescue parser. After switching to sh parser, we can
parse sh-like scripts.

4. Menu viewer
Kernel don't have menu viewer. After loading a menu viewer, we can
display menu items.

5. normal.mod
normal.mod runs the following process to switch to normal mode:

loads dynamic commands from commands.lst
loads auto fs modules from fs.lst
register handler commands from handler.lst
switch to normal reader
execute parser.sh to start sh parser
execute menu_viewer.text to start text menu viewer
parse grub.cfg

-- 
Bean