[ On Friday, January 28, 2000 at 12:01:00 (-0800), Jonathan Stone wrote: ]
> Subject: Re: serial console HOWTO? 
>
> 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.

Yes, this is a potential problem identical to the one where you use a
KVM switch that fakes the keyboard connection at all times.  I do agree
that there must be some way to hard-wire the console device without
having to re-compile and/or re-install the bootblocks.

> 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.

I always do this with a soldering iron (or patch panel), but....  :-)

> 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.

I've never met a slow terminal that won't work quite well at the proper
baud rate.  My original vt100 won't work well without flow control at
9600bps but it works perfectly at 2400, and even 4800 IIRC.

You're right though that if you don't know you need to slow it down then
you'll have a really hard time figuring out what's wrong, especially if
you don't have much experience with serial terminals.

The equivalent of "stty ixon ixany -ixoff" is probably safest.  What's
important is that it not ever be changed after "init" starts.  If you
want to change terminal to a more capable one then you should have to do
something a lot harder than changing /etc/gettytab or running "stty".
Either that or the kernel needs to ignore such changes when it writes to
the device (i.e. any changes should apply only to user processes writing
to the device).

The only problem is what to do if the terminal never sends any character
after it's sent a ^S (which is effectively the scenario I have now).  I
think in this case a timeout should always clear the STOP state after a
few seconds (regardless of whether it's from RTS/CTS or XON/XOFF).

> 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.

My scheme works very well for me in my lab, but then I normally use a
serial console server there too.  The best thing is I can treat my i386
and my sun machines identically.  it should work equally well in any
environment where you have to be physically near a machine in order to
purposefully re-boot it too -- you just have to have access to the
terminal server if you want to actually see it boot multi-user once
you've pulled out the temporary keyboard you used to fiddle with the
BIOS settings.

> 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).

I'm almost of the mind that /dev/console should be eliminated.  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>