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

[Bean]

On Mon, Jul 21, 2008 at 4:02 AM, Marco Gerards <address@hidden> wrote:
> Hi,
>
> Bean <address@hidden> writes:
>
>> First of all, we can still keep rescue and normal command. But instead
>> of depending on normal.mod, normal command depends on module arg,
>> which is an option parser. Also, these two type of commands are of the
>> same command set. In fact, module arg is implemented as a pre parser,
>> which goes through the list of arguments and extract the options. In
>> the case of rescue command, the pre parser field is null, which means
>> it wants to parse options itself.
>
> pre parser?

Maybe not the best word, the idea is that normal command is just like
rescue command, except that it goes through an extra parser that
convert options to grub_arg_list.

>
>> Then, I think of a new structure to represent all configurable
>> handlers of grub. Different types of handler have different fields,
>> but they all share a command header:
>
> What is a handler and what are its responsibilities?

Actually, handler is a genetic term. For terminal, there is grub_term.
For video, there is grub_video_adapter. They're similar in operation.
For example, there can have multiple objects, but only one is active,
they all have basic field like init, fini, next, name. They can be
handled by the same function. I also extend this concept to other
objects, like script engine, console and menu interface.

>
>> struct grub_handler
>> {
>>   .next,
>>   .name,
>>   .init,
>>   .fini
>> };
>>
>> Same type of handlers are linked together. We first define an enum to
>> list all types. For example:
>>
>> enum {
>>   GRUB_HANDLER_INPUT,
>>   GRUB_HANDLER_OUTPUT,
>>   GRUB_HANDLER_CONSOLE,
>>   GRUB_HANDLER_MENU,
>>   GRUB_HANDLER_SCRIPT,
>>   GRUB_HANDLER_NUM
>> };
>>
>> Then, we define an array to point to the head of handler linked list:
>> grub_handler[GRUB_HANDLER_NUM];
>>
>> Head is the default selection. When we insert a new handler module, it
>> would automatically become the new default, although we can switch
>> back to old handler using a command.
>>
>> Here are more details about different handlers:
>>
>> input:
>> This is the input component of terminal:
>>
>> struct grub_handler_input
>> {
>>   .next,
>>   .name,
>>   .init,
>>   .fini,
>>   .checkkey,
>>   .getkey
>>   .flags,
>> };
>>
>> output:
>> This is the output component of terminal:
>>
>> struct grub_handler_output
>> {
>>   .next,
>>   .name,
>>   .init,
>>   .fini,
>>   .putchar,
>>   .getcharwidth,
>>   .getxy,
>>   .gotoxy,
>>   .cls,
>>   .setcolorstate,
>>   .setcursor,
>>   .flags,
>> };
>
> Sometimes the input and output are tightly coupled.  How do you want
> to handle this?

Some module can export both input and output handler, like serial. But
some only export input (like atkeyboard), or output (gfxterm).

>
>> console interface:
>> It represent the grub console, users type commands and execute them
>> line by line.
>>
>> struct grub_handler_console
>> {
>>   .next,
>>   .name,
>>   .init,
>>   .fini,
>>   .run
>> };
>>
>> menu interface:
>> It represent the menu, users select a menu item and execute it.
>>
>> struct grub_handler_menu
>> {
>>   .next,
>>   .name,
>>   .init,
>>   .fini,
>>   .run
>> };
>>
>> script engine:
>> It's responsible for parsing config file to get the menu list, and
>> execution of commands.
>>
>> struct grub_handler_script
>> {
>>   .next,
>>   .name,
>>   .init,
>>   .fini,
>>   .readconfig
>>   .getmenu
>>   .execute
>> };
>
> What I had in mind was a twofold.  I wrote a parser part that actually
> parses the script and code to manage the AST and to execute it.  It
> would be easy to extend the current design with other languages.
> Although I think we should not add more than one to SVN, otherwise it
> will become bloated.

Right, but actually, there are already two script engine existing. One
is the normal bash-like parser, another is the command line scanner in
the rescue mode.

>
>> The handlers are independent of each other. When they need something,
>> they called specific function of the default handler. For example, to
>> read a key from the console, we can use
>> grub_handler[GRUB_HANDLER_INPUT]->getkey. Also, to get the list of
>> items to be displayed on screen, the menu handler can call
>> grub_handler[GRUB_HANDLER_SCRIPT]->getmenu.
>
> How does this differ from what we have now?  You can register all
> kinds of objects and deregister them.

Yes, handler is just objects, but they share common fields, so that we
can handle them together, other than writing different code for
different object.


-- 
Bean