On Fri, Jul 18, 2008 at 2:58 AM, Pavel Roskin <[EMAIL PROTECTED]> wrote: > On Thu, 2008-07-17 at 11:24 +0800, Bean wrote: > >> Any comment for this idea ? > > Maybe you could describe was it will give us and what the drawbacks may > be? It's hard to comment on the implementation ideas without seeing the > bigger picture.
Hi, In the previous thread "Idea: elimination of the normal mode", I have listed some of the reasons. Here are the advantages of this scheme: 1. One command set One of the annoying thing of current implementation is that it has two command set, rescue command and normal command. Some command that can be called in both rescue mode and normal mode have two modules, like linux.mod and _linux.mod. What's more, normal mode command depend on normal.mod, so if we want to include search.mod in grub-mkimage, normal.mod will be included as well, which make the image quite big. But if we take a look at the two command sets, one major different is that rescue command pass argument directly to command, while normal mode command parse it first to get options, then pass it and the rest of argument to the command. Therefore, normal command is essentially rescue command plus argument parser, we can unify them into one command set. Also, normal command would only depend on argument parser, which is a lot smaller than normal.mod. 2. Separation of script engine and interface Another thing about normal.mod is that it bundles script engine and interface handler together, which makes it more difficult to extend its function. We can split the two components: Script engine is responsible for parsing config file, getting menu list, and execution of commands, etc. Interface is responsible for drawing the menu, handling user input, etc. These two component are independent. For example, when interface module want to know the menu list to draw on screen, it asks script engine for it, instead of calling a fixed function. Rescue mode and normal mode uses different script engine and interface. Rescue mode: The script engine is a basic line based scanner, which splits the command line using space. The interface is the rescue shell, which accept user input, then calls the script engine to execute it. Normal mode: The script engine is a bash-like parser, it can return menu list as well. The console interface is a little advanced than the rescue shell, it has auto completion and history. The menu interface is the normal menu, it calls script engine to get the menu list, and uses it to execute commands when user select a menu item. Other possible interface: simple menu: Some terminal doesn't support arbitrary cursor position, so we could implement a simple menu interface where the available items are displayed line by line, with a number indicator. User can choose them using the indicator. graphic menu: It's difficult to merge graphic menu with text menu, as graphic mode provide more features. Graphic menu can use a style config file to control the drawing of windows, while in text menu, there is really not much option available, so we just hard-coded the drawing in the module. 3. Highly configurable After we seperate the above function from normal.mod, we have a highly configurable system. We can select the component we wanted in grub-mkimage. What's more, as there is a basic line based scanner, we can use it to setup the initial environment, like locating root using uuid, setup parameter for serial console, and so on. This feature looks like the preset menu in grub legacy. It also works well in embedded environment. For example, if we want to use grub2 to boot directly, there is no need to include the interface components. Also, if we have included advanced console in core.img, there is no need for basic console. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel