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

[Marco Gerards <mgerards@xs4all.nl>]

Hi,

Bean <bean123ch@gmail.com> 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?

> 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?

> 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?

> 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.

> 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.

--
Marco