In message <m12EE5R-000g7CC@most.weird.com>Greg A. Woods writes

Greg,

It seems think the way I'd like to use serial consoles has more in
common with your feature set than what NetBSD currently has.

For some systems, I'd acutally like to leave video cables and
keyboards hooked up (at least potentially), but still use the serial
port as the default console.  This seems equally hard to do with your
scheme.

I tend to agree with you over flow control, but for different reasons:
inband vs. out-of-band.  And I think the real issue isn't so much
_which_ flow control to choose, but the failure modes if the serial
terminal device and the NetBSD system disagree. I think that argues
for some slightly special handling on serial consoles: asserting DTR,
ignoring deassertion of DCD, perhaps fudging hardware handshake.

Making it _impossible_ to use XON/XOFF is a bad idea: people stuck
with slow terminals that dont have pins for rts/cts will find that
just as incomprehensible as you find the current bootblock setup.

Plus, I can see how the current bootblock setup could be useful in a
lab environment. I think there's a huge difference in expectations
between setups that're physically remote, and setups that're
intermittenly tended (like Matthias' rad-environment lab), where
machines dont get rebooted unless someone physically goes to the
machine.

But (if I understood all the privat eemail, and I'm definitely not
100% at the moment) both Matthias and Martin agree that we need
defaults which go the `other' way.


Last, just FYI, I tried FreeBSD on one of the ServerBios motheboard
machines.  (See the URL Miles Nordin posted, one I posted seems to've
disappeared from the FreeBSD server in the meantime.)  FreeBSD's
three-stage bootloader and bootloader options file made it a breeze to
set up what I wanted. FreebSD supports a flag to toggle to the `other'
console (i.e., the one not autodetected).  It'd be even better with an
option to explicitly select kbd/vga, or a specific serial port,
irrespective of what was autoprobed.  That gets around e.g., remote
staff who forget to re-set a KVM switch to an unused port, or the
"smart" KVM switches which always fake a keyboard.


The only problem is that reading bootblock or kernel options out of a
file in / doesn't generalize at all well to netbooting.

Personally, I think dual consoles (a device that outputs kernel
printfs, ddb output, etc. to both VGA display and serial console, and
ideally, accepts input from either) a better solution to just about
all of these problems. I've talked some with Matthias and Martin about
that; but its a long-term project to put that into the kernel.
(Bootblocks are relatively simpler).