> That's great news for the x86 people but what about the SPARC,
> m68k, MIPS, Vax, NS32k and others that have no com.c in their
> architecture?

The change to implement bidirectionality is not machine
dependent even though it is in a machine dependent file.
Ideally com.c (and its counterparts for other architectures)
should be split into two parts such that the machine
independent part is shared by all arch.  Sort of like tty.c
except at a lower level.

> As a religeous note: I see having to use 2 seperate devices as
> an icky kludge.

Think of ttyXX and cuaXX as two separate *views* of the same
object.  Having multiple views (or interfaces) to the same
object is actually a very useful idea in general (and used a
lot in the database field).

So this does not bother me but then I am an atheist :-)

>                 It isn't necessary if the serial port driver
> is written correctly. I used dialin/dialout with one serial device on
> Amiga UNIX SVR4 for 4 years, with ttymon no less, and it all just
> worked. I see no reason why the general serial port code couldn't
> do what other OS's have been doing for years.

It is just easier with two devices.  I don't have to modify
my 10+ year old programs or depend on cooperating programs
or worry about which of /{usr,var}/{lock,locks,spool/uucp}
dir. should be used for a lock.  The time window during
which incoming calls will be missed due to a switch over
from outgoing to incoming is also much smaller with a kernel
based implementation.

As long as I can make my local changes to com.c I am happy
so I don't particularly care if I haven't convinced you or
anyone else!  *Another* very good reason for using systems
with access to source.

Bakul