IMHO. Current system with title command is ugly because:
-grub.cfg requires the separate parser. IMHO it should be
parsed the same way as user input.
-Even when scripting support will be ready it's impossible
to create multiple menus of the same kind by just a loop
(like
for x in /boot/vmlinuz-*;
do
menuitem name="linux-$x" title="Linux with kernel $x"
linux $x [....]
endmenuitem;
done;
)
- if in future menu entrys will have more parameters
(e.g: name, keyboard shortcut) how could we specify them?
As arisen in discussion about serial console multiple menus could be
useful. I propose to split munu.c in general (e.g: run_entry) and
menu-specific (like run_menu) and then make multiple menu support like
done with terminals. Then we could add other menus: like lilo menu
(additional parameters could be stored in variable: then boot function
could also look at this variable for parameters (of course parameters from
unauthorized users will be ignored)), vesa menu
(and 3rd party programmers could write vesa menus then it would be like
skin support), x-menu over ssh/network, ...
IMHO grub2 needs scripting support to be more powerful I propose to
use bison translating commands in the structures like:
struct command
{
enum type {SCRIPT_CMD_NORMAL, SCRIPT_CMD_IF, [...]}; /* type of
command*/
enum link {SCRIPT_LINK_NORMAL, SCRIPT_LINK_AND, [...]}; /* Was there
a &&, ||, ... before command?*/
union
{
char *command;
struct command *if_jump; /* Bison could translate the condition
as preceding command*/
[...]
}
};
then menu-entrys could be
menuentry name=<name> title=<title> [key-shortcut=<..>] [picture=<...>]
<....>
endmenuentry
I'm ready to make the work of menu-splitting, lilo-menu and scripting
What do you think about it?
Vladimir
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
