On Wed, 19 Jan 2000, Jonathan Stone wrote:

> Ick. I bet none of them are Emacs users, then.

First of all, I don't know that the DIRECT_SERIAL output code actually
respects XOFF.  Possibly, hopefully, it does, but I wouldn't take it for
granted. I merely know that it's capable of ignoring RTS in case that wire
isn't there.

Second, just because DIRECT_SERIAL treats the port in a certain way
doesn't mean that your console acts that way when you login. DIRECT_SERIAL
doesn't do _anything_ once the bootblocks pass control to NetBSD.  The
NetBSD kernel's treatment of the serial port is always just that, and is
handled by the same code whether your bootblocks used INT13h or
DIRECT_SERIAL.  NetBSD/i386 does not make callbacks to the BIOS or the
bootblocks for pre-wscons-attach console output like it does on some other
platforms (right?), so whatever quirky implications of DIRECT_SERIAL there
are don't extend beyond choosing which kernel you want to boot.

Third, I believe serial console kernel-printf output may be subtly
different from console interactions through the tty layer, even on a fully
running system.  I don't understand exactly how the output is routed.
But, for example, don't assume kernel printf's respect flow control.
Maybe they do.  It's just, separate, so it's something to think about.

I realize this is complicated, but there are necessarily some
chicken-and-egg problems in any booting/crash-contingency framework.  A
good framework will have things arranged so that features/complexity is
uniformly added (not changed/removed) as the system comes up.  This is
about the best you can do, and I think it's what DIRECT_SERIAL is
attempting.  Requiring an RTS signal, then removing the requirement later
in the boot process, is confusing. Not supporting RTS at first, then later
adding code to respect it, is sane and intuitive.

But, I need to give the preaching a rest.  The useful take-home message is
that if you need hardware handshaking to use emacs or wahtever, then you
probably need to look at /etc/gettytab and explicitly set up your console
port the way you want it.  I'm not too knowledgeable here, so if the man
pages are too obscure perhaps someone else can step in to help you with
this.  The basic scheme (appologies if this is review) is that "getty Pc"
in /etc/ttys points to the "Pc" entry in gettytab.  The gettytab entry
sets speed, flow control, DCD SIGHUP behaviour, that sort of thing.  
However, you shouldn't have to worry that your boot blocks are having any
limiting impact on the tty options you can use once the system is booted.

> These days, PeeCee server motherboards are real computers,

I absolutely won't go along with this, and everything you've told me about
them so far re-inforces my opinion, even including the strange idea that
``servers'' are somehow different from regular computers.

And yet, I do understand that things _are_ changing--i suppose we will
have to agree to disagree on exactly _how_ they are changing.

> the BIOS would really rather use CTS/RTS handshaking, it wants DCD
> asserted,

This sounds needlessly restrictive to me.  Do you actually need
CTS/RTS/DCD functionality for your console, or are you really just asking
for a line that's transparent to ^S and ^Q?  Because I don't think you
need the former to get the latter (gettytab, above).

BTW if you want a speed besides 9600 with the DIRECT_SERIAL code, you can
use the CONSPEED #define.  I believe this will percolate through the first
few layers as the system comes up, but you might still need to update
gettytab with the higher speed or maybe the port will get pulled down to
9600 after the system goes multiuser.  sorry--haven't tried CONSPEED
myself yet.

Regarding the 3-wire library terminals, I believe you can get the shims I
spoke of from Black Box or similar.  There may be MMJ versions available,
but the target market I was thinking of wants to cheapen the wiring you
have to buy, so the ones I was thinking of are definitely standard telco
jacks.  Since telco wiring is only 4- or 6-conductor, providing RTS/CTS,
DTR/DSR, DCD, can be problematic.  There's no reason you can't just do
loopback wiring for these, but the point is to keep things simple. I
understand you wouldn't want to run PPP over such a line.  It's just that
booting interactions tend to be debugging-oriented--you don't pay
attention to them until they're broken.  

It's thus more important that the thing interact with you usefully than
have lots of features, like flow control and modem commands.  You don't
need optimal performance just to read kernel printf's and use ddb--it's
all right to set the console speed low enough that you never need to XOFF
or lower RTS.  What you need is something that doesn't require you to
debug wiring when you have more desperate and essential problems on your
mind. I just like mamking things easy on myself, and not wondering if the
machine is fried when no output comes out of the console port.  I can
understand if others feel differently--this just makes a lot of sense to
me.

I have to wonder, would we even be having half of this discussion if the
RS232 designers had been smart enough to explicitly define the
high-impedance state of the RTS input pin as ``on.'' But of course when
foolish engineers make a plug, they sloppily default all pins to ``off''
regardless of their function.

My math teacher pointed out to me that RS232 should have been like this:
 1. All devices have ports wired the same way.
 2. All devices are female, and all cords are male on both ends.
 3. All cords have Tx/Rx, RTS/CTS crossed inside them.
 4. All F-F gender changers have Tx/Rx, RTS/CTS crossed inside them.

(it turns out that telephone cords and telephone F-F extender adapters
work in exactly this way, BTW)

If it were done like this, the frustrating concepts of DTE/DCE and ``null
modem'' cables would just go away.  I know this is off-topic.  I simply
want to point out that there is a _lot_ of subtly bad design going on out
there, and that the mistakes have real and painful consequences.

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US