Okuji
I like your proposal. Something like "menu" do display the menu in text
only etc. It would be nice to number the entries so that "menuline 5" or
similar would select it.
Christoph,
I do not see the need to make functions out of the menu entries. I do
think there should be a way to choose one by name.
I do agree that it would be nice to be able to specify a server as you
write in "root (nd:192.168.1.20)" format!
I'm not so concerned with loading a network config file. If you have
access to the server to setup the config file, it is likely that you
would also have access to the dhcp server to install it. I guess it
would be nice for the other cases, just not a priority on my list.
Great comments though! It shows that you have been putting some thought
into it.
Christoph Plattner wrote:
>
> Hi !
>
> Your proposal sounds good for me.
>
> One idea to the to the menu replacement for dump support.
> A good idea seems to have something like functions !
> You define `function XXX' instead of `title XXX' in the config file.
> All functions defined can be called on the command line.
>
> We can further do:
>
> function boot_linux
> root (hd0,0)
> kernel /boot/bzImage
>
> function boot_linux_nfs
> root (hd0,0)
> kernel /boot/bzImage.nfs root=/deb/nfs
>
> title Local Linux Boot
> boot_linux
>
> title Remote Linux Boot
> boot_linux_nfs
>
> Of course function names must not conflict with commands (builtins).
>
> Or we use special tokens, like
> *boot_linux
> to distinguish between commands and functions.
>
> ----
>
> When I speak about functions and menu items, then I want add one
> more thing.
>
> It could be to add a key word menu to the config file, to explain
> the parser, that the following part is a menu. My idea is to use
> the config file also only for config or setup without menu
> functionality (for example to setup functions, ther serial console
> and nothing else .....
>
> function boot_linux
> root (hd0,0)
> kernel /boot/bzImage
>
> function boot_linux_nfs
> root (hd0,0)
> kernel /boot/bzImage.nfs root=/deb/nfs
>
> # here we start menu definition
> menu
>
> title Local Linux Boot
> boot_linux
>
> title Remote Linux Boot
> boot_linux_nfs
>
> So it should be possible to define a default action to call a
> function as we have a default menu boot.
>
> -------
>
> Now the last improvement, not concerning the dump serial support,
> but the use of GRUB in combined local / diskless operations.
>
> First of all, I would like a possibilty to select the server manually,
> instead of bootp (additional) like
>
> server 192.168.1.20
> or
> root (nd:192.168.1.20)
>
> (or is there a possibilty, which I don't know now)
>
> The second is the possibility to call the 'netbooted' menu
> from a local one like
>
> configfile (nd)
>
> or this could be possible with the menu entry
>
> title Netboot Menu
> bootp
> root (nd)
> configfile ???? <---- here we need the keyword
>
> ----------------------------
>
> Sorry that there are so much things in one mail, but there
> are some connections between these options, so it is a good idea
> to have all these things considered for the design change for
> the dump serial support.
>
> With friendly regards
>
> Christoph P.
>
> By the way: I am two weeks on vacation (from monday)
>
> OKUJI Yoshinori wrote:
> >
> > Ok, then I'll add some support for dumb terminal. This is my
> > proposal for the interface:
> >
> > * In the command-line interface, use single-line-editing (like bash
> > with the environment variable TERM set to "dumb"), whether your serial
> > terminal is vt100-compatible or not. That would simplify the
> > implementation, and the overhead of serial communications could be
> > smaller, because we does't need to call the stupid function getxy. The
> > question in that is if we should use single-line-editing mode in the
> > "ordinary" console as well.
> >
> > * In a dumb terminal, don't use the menu interface at all. Instead,
> > provide the user several commands which can manipulate menu entries in
> > the command-line interface. This is much easier to implement than to
> > give the user alternative menu interface.
> >
> > Okuji
>
> --
> -------------------------------------------------------------------------
> private: [EMAIL PROTECTED]
> company: [EMAIL PROTECTED]
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
