Hi OKUJI, hi folks,
I've been very busy (job & family-related) in the last months, so I
could read, but not write nor do anything for GRUB. It's still the same
situation, however, as the action point "Implement serial console
support" arose in OKUJI's TODO list, which is a major concern in our
project, here some words to the issue and some offers for
contribution.
0) We're using a thing called `preboot agent' provided by embedded
BIOSes for serial line support now:
This allows for simultaneous console (=VGA+kdb) & serial (=COM)
work provided entirely by the BIOS. This makes BIOS setup and GRUB
selection/interactive mode transparent (All console I/O is going to
a potentially connected console AND to a potentially connected
serial line).
This stuff is buggy in all aspects, so the request for native GRUB
serial support still exists. (BIOS factory defaults may be OK, but
the need for booting different kernels - via menu.lst - is intact).
Here are some questions and suggestions wrt. serial console - ideas
and criticism welcome:
1) What is the design goal for GRUB: Either go for BIOS calls to
COMs (may be a pain wrt. BIOS implementations) or go for UART
native HW handling in GRUB (I'm not a specialist on strange UARTs,
but the UARTs I had the last decade was OK, at least from the
portability standpoint - UART 8250 - correct me somebody if I'm
wrong).
What I could offer here:
- Assembling or providing some code fragments to handle basic UART
handling macros & routines out of approved (= working) code.
The next assumes that the UART and terminal handling is coded into
GRUB (and not coded via BIOS COM calls).
2) What is the strategy for the "[G]UI":
In an older thread Stephen Early wrote:
You can assume CR, LF and BS. Don't assume anything else. In
particular, don't assume that all the world's a VT100.
Limiting GRUB to a `dumb' terminal (which is not even true for BS)
is a minimalistic approach (hence worth to consider as fallback).
I've some code around which does `qterm' like queries of the
terminal type connected. The question here is what to do after a
certain `TERM' is detected? Linking basic termcap capabilities as
data and a simplistic termcap interpretation library? Fallback is
still to assume CR, LF, and (or not) BS.
The question what to do about timeouts and the "is somebody there"
question still stays (-+crtscts or SW/Handshake, same with stty
stuff like baudrate, cs*, par* ...)
Again Stephen Early:
> 4. Do you want to use both the local terminal and the remote terminal
> simultaneously?
No. However, it would be nice if GRUB could be made to choose between
serial and keyboard input when it starts up by seeing which one
happens first. (Some Alpha firmware has this feature - it's very
handy.)
Stephen is right, but first we've got to decide the "is somebody
there" question.
3) I'd like to see menus derived from menu.lst.
At least something matching the perception of the user. In order
not to fall into the kbd-layout or I18N discussion (until GRUB is
able to load modules?) we could stick to 7Bit ASCII pictures, but
still draw them over SL and find a way for the user to interact in
a natural way.
What about something like (derived from menu.lst titles):
0 My hot operating system
1 Stable GNU/Something
2 Or really Win59?
Select choice? (3 seconds to boot) [0]:
With BS capability, even that works wrt. the countdown.
4) Editing:
When I first saw the serial thread, I start thinking on what to do
about `editing'. The question here being, do we want to be able to
edit on `dumb' terminals. I think we should, since the process of
configuring the boot properly is sophisticated enough to allow
operator errors, and these guys are stuck with an unbootable
machine otherwise (I was always happy to be able to edit my
erroneous menu.lst items without being forced to boot a Rescue
Floppy).
BASH has a fancy feature on the "ONE LINE EDITING" thing, it let
the user move within one line, marking BOL resp. EOL with "<"
resp. ">".
bash> line is short and getting longer
bash> <short and getting longer and longer and longer and longer>
bash> <and getting longer and longer [CURSOR]
It didn't look at the `readline' code yet, but I think it is
getting around the problem with BS and line-redraw only.
In the hope, this helps a bit for GRUB
KR
PS: OKUJI, you mentioned carefulness in Automake checkout in your
latest posting, is there more info (cvs tag or a date string?).
--
email: [EMAIL PROTECTED]
Klaus Reichl [EMAIL PROTECTED]
Danhausergasse 8/16 voice: +43 (1) 27722 / 3884 (job)
A-1040 Wien +43 (1) 94 137 94 (private)
+43 (6991) 94 137 94 (mobile)
