From: Theodore Ts'o <tytso@athena.mit.edu> Subject: Re: The great serial device naming controversy.... Date: 30 May 1993 23:30:42 -0400
From: pdh@netcom.com (P D H)
Date: Sat, 29 May 1993 04:36:53 GMT
Are things really this bad where the names are used as is? The names
should be resolved to a canonical form before locking. This smells of
a broken lock system.
Let me speak to this issue. Bradon S. Allbery has argued before that
technically, there is no need for the /dev/cuaXX device; that if
programs performed the correct locking, that it would be possible for
getty/uucico/kermit/seyon, etc. to all successfully share one device,
/dev/ttySXX.
On this point, he is correct.
However, there are two problems with this approach. First of all, the
locking which the getty program has to perform has to be very carefully
done and programmed. Specifically, while getty is waiting for the
carrier detect line to go high, if it notices that a dialout program has
opened the line it has to close the line and exit. (What this means is
that the getty should monitor the serial port for incoming characters
using the select() system call, and if it sees any, and a lockfile
exists, a dialout program must be using the line.)
I have yet to see a getty program get the subtleties of this completely
correct, and it was easier for me to add the neceesary mutex locking for
/dev/cuaXX in the kernel than it was for me to start maintaing a getty
program.
Secondly, there are at least three or four "standards" as to where to
put the lock files (what directory and what filename) and what the
contents of the lock file should contain. (i.e., should the pid be
written in ASCII or binary format). Again, the most common dual use of
a modem is to share a line for both dial in and dial out purposes. So,
it was simplest to do the mutex locking in the kernel.
Now, having said this, the /dev/cuaXX deveices don't fix all the locking
problems. In the case where you have mutltiple dialout programs, such
as kermit vs. uucico, you still need to do locking. So, the issue with
n different lockfile standards doesn't go away, really. People still
need to pick ONE locking standard, and stick with it.
Finally, for those people who think the /dev/cuaXX device is an
abomination, or shouldn't exist, they can ignore it. It is perfectly
acceptable to completely ignore the /dev/cuaXX devices and just use the
/dev/ttySXX devices. The /dev/ttySXX devices are fully POSIX complaint
--- up to and including the requirement that opening them without the
O_NONBLOCK flag will cause them to block if carrier detect is not
present. (Yes, this is mandated by the POSIX spec; look it up yourself.
The reason why /dev/cuaXX does not have this requirement is that many
dialout programs are broken, and don't really work with truely POSIX
behavior). Of course, I haven't seen a freely available getty that will
work with other dialout programs sharing a POSIX serial port, but maybe
one of the purists will write one, one of these days. :-)
In the meantime, what I would suggest is that people use a getty (such
as 2.0.7) on /dev/ttySXX, and that all other dialout programs use
/dev/cuaXX. I suggest that the authors and distributors of the dialout
programs choose a lockfile standard amongst themselves, so that dialout
programs can lock each other out.
- Ted