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]
