In message <Pine.NEB.4.05.10001191717230.10470-100000@audrey.Ivy.NET>Miles Nord
in writes
>On Wed, 19 Jan 2000, Jonathan Stone wrote:


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

Sure. I assumed the bootblocks passed on the exact same info they
used, including handshake info .  That was probably a mistake.


[....]


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

Why does it reinforce your opinion? Have you tried firing up a
motherboard with ServerBIOS, looking at the hardware error-logging
features of an IPMI/EMP-equipped board? The remote-front-panel
facililties?  It's not solely for Windows; VA-Linux's VACM cluster-
managment supports it on Linux. If they can get the docs, we can,
or reverse-engineer it from theirs.

Once upon a time, I used to run large VAXes. High-end Intel server
platforms can now do pretty much everything that, say, the RDM boards
in a vax used to do, or the vaxcluster management sw running on a
dedicated Microvax could do. That sounds pretty "real computer" to me.

And yes, intel "server" motherboards _are_ different from Intel
"desktop" motherboards. In much the same way a 6000-series vax was
different from a 3100-series desktop vax.  See:

	http://developer.intel.com/design/servers/n440bx/
	http://developer.intel.com/design/servers/l440gx/
	http://developer.intel.com/design/servers/t440bx/

It's mostly marketing junk, but look for the keyword "server
management microprocessor" and "emp".  You dont get those on
desktop Wintel motherboards.  That's the difference. Or check out 

	http://www.valinux.com/projects/vacm/


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

Uh, s/_are_ changing/_have_ changed/, from where I'm sitting.
At least a year  ago, if the NetBSD archives are to be believed.


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

Let me try and work through this once more.  I'm asking for a line
that's transparent to DC1/DC3, so I can use emacs without going
insane.  I also want a line which does _some_ handshaking, so it won't
trigger overruns when the serialbios maps all those funky BIOS menus
onto ANSI X3.64 escape sequences, and blasts an entire screenfull of
them them down the serial line.  If XON/XOFF is out, that leaves CTS/RTS.
No?

The tricky issue here is setting up flow control on the
terminal-server side, and getting it to match what the other end is
doing. If the other end's behaviour depends on whether it's in the
BIOS or in the bootblocks or in the kernel, then you're going to have
problems.  Obvious, no?


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

Ok. Thanks for the tip. I'll have to try it.  The BIOS serial console
supports 9600, 19.2k, 38.4k and 115.2k; it'd be nice if the ASCII
screen-painting doesnt get _too_ far behind the BIOS delay loop.
Otherwise you don't know when to send an F-2 down the serial line to
to into BIOS setup. That's a motive to run at high speeds.  Which 
in turn is a motive for  flow control....

In an ideal world, the bootblocks could ascertain that the BIOS is
using a serial line as console, obtain the line speed, etc. from where
the BIOS keeps it, and pass it onto the console.  I think we all agree
on that.  If I get anything back from Phoenix, I'll post it.

[snip]

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

Once again, I think we have different assumptions. I want this line to
be _more_ reliable than your average PPP line.  I want to use serial
consoles as _the_ primary cosole for the machine. Assume I dont have
phyiscal access to this machine more than, oh, once or twice a year.
The design tradeoffs are then very different than debugging (in the
sense of hands-on debugging) a boot process, or monitoring lab equipment.

If you think of a Sun, or an Alpha, located in a physically-secure
remote wiring closet (or co-located at an ISP, even), using a serial
port as console, that's much closer to what I want to do. (The
tradeoffs in FreeBSD's serial consoles seem much closer to that,
btw.).


>It's thus more important that the thing interact with you usefully than
>have lots of features, like flow control and modem commands.

Nope. I think that's another mistaken (or different) assumption.  I
_dont_ want human interaction here. I want to set up a DB-9 cable from
a serial server, and run Vixie's rtty. So that console error messages
get logged reliably, even if the machine crashes without syslogging
them.   (And so that there's a record of what got done via the console).

I may want to do occasional forced reboots, or remote hard resets,
in case of hardware failures (I just ran into one).  Or reset balky
second CPUs after a crash, if we supported SMP (sigh).  The usage
patterns for that are very, very different from a "debugging" setup
or monitoring lab hardware.  Which is what the current serial-console
code seems aimed at, at least to me.


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

Debug wiring? Nope. Cut to length, crimp on connector, screw or clip
down at both ends and every few feet, and forget it.  The doors on the
closets are very secure.

If I'm worried whether the machine is fried, I'd check via the EMP
port.  That's what it's for. It can tell me whether the machine is
alive or not, and it uses a separate microcontroller to do that.
Plus dual hotswap power supplies.  Suspenders and belt.

[... digression about RS-232]

Was your math teacher a radio ham? A boss of mine once said that, over
15 years ago. z9m9z, i think -- something palindromic and reminiscent
of E.E. Smith.  But thats way off-topic.