Re: [DISCUSSION] Scripts and menus

[Douglas Wade Needham]

The problem with your idea is that it at least appears to be too
Linux-centric, and forgets entirely about other operating systems,
invalidating the "unified" part of the GRUB name.  And I get fed up
when on my machine which as FC3 has one of the OSes (along with NetBSD
and several others), up2date ignores the fact that FC3 **is not** the
default.

BTW...If 1.9 is supposed to be indicating that we are nearing a 2.0
release, I don't think that now would be the time for such a major
change.  After nearly 30 years of programming, one of the problems I
have seen in too many Open Source projects is that a release cycle is
supposedly started, but...

    1) No release branch is started in the source repository.

or

    2) Major, non-critical changes are committed to the release
       branch, which in turn delay the release or make it unstable.

In short...if you have the features in which you have decided upon for
a release, branch, start testing, and the only thing which goes on the
branch are fixes for problems or pullups related to security.  All
other work stays on the mainline branch for the next major release.

Just my opinion...

- Doug

Quoting Vladimir Serbinenko (address@hidden):
> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!