>} I am happiest with the SunOS /dev/ttyN vs /dev/cuaN game -- it works
>} *VERY* well, and it is the one thing from SunOS I miss in NetBSD.
>
>     I second this.  It's really annoying to have to shut off the
>getty and set clocal on a port everytime I want to dialout or talk to
>a modem using cu.  I know could do a kludge, i.e. install mgetty, but
>I shouldn't have to do things like that.  It should work properly out
>of the box.  Once upon a time, cgd produced a patch to implement this
>functionality, which I still have somewhere.  It would be nice if that
>patch could be redone for the current com.c.  The SunOS method was
>really nice.  Attach a getty to one port, do whatever you want with
>the other, and it all just worked (the way things should be).

This is one of those long-running flame wars that come up occasionally :-)

One group loves the cua scheme.  Another group hates it and denounces
it as the spawn of Satan.

Having used it for many years, I am mostly happy with it; the right
things almost always seemed to happen.  However, there have been a few
times where the tty got into a weird state and required a reboot.  That
sucked.  It happened often enough that I remember it, but never often
enough that it was disabling.

I can understand the arguments against it; it moves some locking into
the kernel that might be better left to userland, and it's generally
not been possible to reset it when it went south (except rebooting,
of course :-) ).

I believe the general objections to the previous implementations were
that they were tied to particular hardware, where this feature really
should be made generic and put into the tty layer.

I think it's worth pointing out that Linux used to have this scheme,
but they ended up reverting back to the "normal" scheme after a while.
(At least, that's what I remember happened ... I'm not 100% sure of
the details or the reasons why).

--Ken