Hi Matthias,

Sincere thanks again to you and Dave Maxwell for the suggestions.

I do get the feeling, though, that:
   a)  I'm trying to do something which is  much closer to say,
       an ISP with a rack of Alphas or Suns using serial consoles,
       where _all_ administration is done via the serial console;
       
   b)  that the requirements there are  very different
       than your lab setup, or my own lab setup for that matter;

   c)  that NetBSD's serial consoles are not at all a good fit
       for that environment, at least with ServerBIOS
       serial consoles thrown in;

   d)  the current code and design is not at all amenable to
       reworking to match my goals.


In an ideal world, i could turn on the Phoenix ServerBIOS serial
console (http://www.phoenix.com/platform/serverbios.html), NetBSD
would recognize that, use the same port as serial console, and
everyone would be more-or-less happy.  I've asked Phoenix how to get
technical information on the serverbios.  I have no idea if they'll
give a helpful answer, but I have tried.

I'm sure I can get something to work using the ServerBIOS serial
consoles and the kernel overrides.  Longer-term, the serial-console
design needs severe changes to better fit an ISP-style usage model of
what "serial console means" than the usage which (from what you say)
is designed more for a lab-style model.

I want untended operation, with human presence very very rare.  I want
hardware flow control, because the serial console is supposed to
always be wired up (and something is screwed up badly if it isnt, and
I'd like to know, so I can fix it).  I want explicit human
intervention before using the "other" console, with automatic
reversion to the "default". If using "autosense", I want the default
to be the serial console, but treating operator input on the normal PC
keyboard as a signal to use the "internal" devices as console.

On every point, you seem to want serial consoles to do the exact
opposite.  I'm not sure there's room for common ground here. Other
than dual console devices (send output to both, accept input from
either), or an lage set of options. Perhaps unmanageably large.


I make time cycles in February to do some work on this, if we
can agree on how to go about it. I do think we have a fundamental
architectural disagreement about whether the right model
for serial consoles is "tended" operation or "untended" operation;
and we need to resolve that before we can make headway.

Does that sound like a fair summary to you?