david@fundy.ca said:
> Rather than trying to address individual comments, let me see if I can
> sum up where things are today (and be corrected if I've misunderstood
> something) - and where they could be improved. 

Thanks for writing a mail which is shorter than one page:-)

I'll add some comments (from my POV of course).

> Today:
> 	Bootblock parameters can only be changed with a re-compile and
> 		install.
Yes. (Mostly due to lack of persistent storage.)

> 	Flow control handling can not be maintained consistantly from
> 		boot to multi-user, except for XON/XOFF+ixany.
That's a more complex issue. There are 3 instances (or 4, if you count
a "server BIOS") doing output:
1. Bootloader. It can do either hardware handshake (with INT14h I/O),
   or ixon+ixany (with direct hardware access). There is a good reason
   to do ixon per default: A terminal might send an XOFF on bootloader
   output, and the bootloader would take this as keypress, interrupting
   the boot process, if it didn't understand the software flow control
   characters.
2. Kernel console output. Doesn't do any flow control. (There are
   DOS issues, as Martin points out.)
3. /dev/console output. Goes through the tty layer, parameters set by
   userland.
Since (2) doesn't do flow control anyway, there is not much to do
consistently.

> 	You can default to xGA, with an interrupt out to serial console,
> 		but not do the opposite.
You can actually do the opposite, but through another mechanism:
Disable the serial line in the BIOS.

> Improvements:
> 	Some form of persistant storage for options.
Isn't available on standard PCs. Some config file in the root
filesystem would be possible, but:
-bootstrap issues: access to this file is already complex enough;
 we want a console to watch its progress/failure
-doesn't scale well for network boot
What we could do is to support patching these variables in the
bootloader binary with gdb or installboot. Doesn't work for
boot ROMs, obviously.

> 	Options for flow-control type, and ability to pass it to the 
> 		kernel.
Pointless as long as the kernel doesn't care.

> 	Options to allow, or prevent, interrupting to another console.
> 		(Even after boot??)
Could be made more easy, agreed. At least as far as the bootloader is
concerned. I doubt however that there is a configuration which
satisfies everyone: An autoselecting terminal eg will happily send
its output to a serial mouse (to a modem probably too).

> 	Options to duplicate output on multiple devices.
Would have its advantages, in some cases. Not in others, as in
the mouse case above.

best regards
Matthias