Re: [PATCH] Split of normal mode (version 2)

[Bean]

On Sun, Apr 5, 2009 at 10:33 PM, Yoshinori K. Okuji <address@hidden> wrote:
> On Saturday 04 April 2009 14:06:18 Bean wrote:
>> One of the problem for normal.mod dependency is its side effect. For
>> example, currently ls.mod depend on normal.mod just for
>> grub_normal_print_device_info. If we want to embed ls.mod in core.img,
>> we must embedded normal.mod as well, along with a lot of
>> initialization actions that we may not want.
>
> Right, if we can completely merge the ls on rescue mode and that on normal
> mode. For now, I am not sure if this is feasible, so I prefer to keep a poor
> version of ls for rescue mode, which does not require functions in
> normal.mod, until you prove that that is feasible.
>

Hi,

Currently, this is implemented using priority list. The commands has a
field that indicate its priority. For normal command, the value is 0,
for extended command, it's 1. So if two version of ls is loaded, the
extended ls would be used. All commands are in a unify set, so you can
run normal commads/extended commands in either rescue or normal mode.

>> We can generate a handler.lst by scanning source for
>> grub_parser_register, etc, just like commands.lst:
>>
>> parser.sh: sh
>> reader.normal: normal
>> menu.textmenu: textmenu
>> terminal_outout.gfxterm: gfxterm
>>
>> We can then read it in normal.mod and set the hooks for all handler
>> classes.
>
> I like if you can merge all kinds of handlers this way, thus eliminating the
> command.lst and the fs.lst.
>
> But I still think that having commands for parsers and menus, since you can
> do:
>
> grub> sh /boot/grub/foo.sh
> grub> textmenu
> grub> gfxmenu
>
> They won't be very useful for most people, but could be useful for
> development.

Yeah, that's possible. We can register a generic command to do the task.

-- 
Bean