From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KKf6d-0001pM-1v for mharc-grub-devel@gnu.org; Sun, 20 Jul 2008 16:02:07 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KKf6b-0001lt-EF for grub-devel@gnu.org; Sun, 20 Jul 2008 16:02:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KKf6a-0001jk-K9 for grub-devel@gnu.org; Sun, 20 Jul 2008 16:02:04 -0400 Received: from [199.232.76.173] (port=39315 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKf6a-0001jW-GR for grub-devel@gnu.org; Sun, 20 Jul 2008 16:02:04 -0400 Received: from smtp-vbr11.xs4all.nl ([194.109.24.31]:4553) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KKf6a-0003NL-5J for grub-devel@gnu.org; Sun, 20 Jul 2008 16:02:04 -0400 Received: from localhost.localdomain (249-174.surfsnel.dsl.internl.net [145.99.174.249]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id m6KK22HK022855 for ; Sun, 20 Jul 2008 22:02:03 +0200 (CEST) (envelope-from mgerards@xs4all.nl) From: Marco Gerards To: The development of GRUB 2 References: Mail-Copies-To: mgerards@xs4all.nl Date: Sun, 20 Jul 2008 22:02:50 +0200 In-Reply-To: (bean123ch@gmail.com's message of "Mon, 7 Jul 2008 08:29:42 +0800") Message-ID: <873am4ias5.fsf@xs4all.nl> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 Subject: Re: Idea: elimination of the normal mode (revised version) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 20:02:05 -0000 Hi, Bean 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