Hello Bill,

In another forum Marcus was discussing Linux, perhaps what he said
also applies to NetBSD?

--------------------------------<snip>--------------------------------
#3 of 3 by Marcus Watts (mdw) on Sun Oct 22 22:10:38 2000: 

Linux is an OS.  Emacs is an application that *happens* to run under
Linux (it was originally written for multics & migrated onto Unix early
on.) I think the ^S/^Q stuff dates back to Multics.  People back then
didn't worry about hardware vs. software handshaking for video
terminals.  The usual problem was what terminal escape codes were
supported.

There are really 3 issues here:
        what does Linux (or Unix) want?
        what does the hardware best support?
        what do the application & data protocols need?
For the OS end of things, it doesn't matter: linux supports both
hardware & software handshaking, equally well.  Full stop, end of story.

For the hardware, things quickly get more complicated.  This is *NOT* an
OS issue, although the particular OS driver insubstantiation may make a
difference.  Hardware handshaking has its own separate data channel.
Software handshake has share the data channel with the data.  This
complicates the design, and can lead to some interesting conundrums if
not thought out carefully.  For instance, older serial interfaces were
generally designed for simplicity, quick response, & low data rates.
They generally provided a 1 character buffer for transmit, and a 1-2
character buffer for receive, plus of course the actual shift registers
for whatever was going in & out.  Even with a fairly simple program, it
was easy to guarantee a quick response (typ w/ 2-3 characters) to a
character input.  For a 300 baud direct connect teletype, that's 1/10th
second at most, perfectly adequate for human response situations.  For a
printer buffer, it was sufficient that a fifo send xoff/xon when there
were still a few characters left in the buffer - 5 characters would have
been plenty of slack.  The early modems did not introduce any
perceptable delay of their own - perhaps 1/2 baud or bit time at most.

Then the complications came.  DMA serial output.  Multiplexed polled
inputs.  Microprocessor driven front-ends.  & all that.  Some of this
hardware, when driven with the right software, could meet all of the
performance specs of the dumb UART, while still cutting way down on
interrupts & character overhead.  Then there were many software drivers
that botched something, and some hardware interfaces that were incapable
of being instructed to do the right thing, and still do it efficiently.
At the same time, the baud rates on everything went up, and modems that
did space compression and error correction appeared.  Now we have 64
character transmit FIFOs (and how do we stop transmitting and then
either resume transmission or dump the queued buffer, without dropping
or duplicating any characterss, muchlater?) At the same time, serial I/O
is a lot less fashionable.  Dumb terminals have practically disappeared,
and cable "modems" are replacing phone modems.  Not surprisngly, not
everything works right, and the old rule of "stop when there's still 5
characters free") is probably not right any more.

Lastly, there is the software issue.  Emacs is its own special (and
stupid case, although not necessarily rms's).  Other protocols that have
better claim that this is bad include many binary transfer protocols,
including uucp (the g protocol), and "modem7".  Some protocols,
including kermit and ppp, support or allow some form of data mapping to
deal with serial connections that aren't 8-bit transparent.  As a
general rule, to support all these protocols, hardware handshake is
best.  But this is not a OS requirement.  It is a software &
applications requirement.

--------------------------------<snip>--------------------------------

_____________________________________________
Free email with cool domains at FriendlyEmail
http://www.mypad.com/