From: andy@madhouse.demon.co.uk (Andrew Bray) Subject: Re: The great serial device naming controversy.... Date: Mon, 31 May 1993 11:15:44 +0000
In article <1ubu52INNaac@senator-bedfellow.MIT.EDU> tytso@athena.mit.edu writes:
>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.
Is it not possible to fix this by the following approach for opening
the cua* devices:
1) If the device is already open by the ttyS name, reject the open.
2) otherwise, if the device is open by the cua name, check the controlling
tty/process group of ANY process that has the device open. Reject
the open if different.
3) Otherwise the open the device.
Thus the kernel can readily allow simple programs to completely ignore
the whole issue of lock files.
I find that I do not really like the usual UUCP style locking scheme.
If there was no kernel locking of serial ports, I would favour the
following approach:
Serial devices are organised as follows:
drwxr-xr-x uucp uucp /dev/serial
crw-??-??- uucp uucp /dev/serial/ttyS0
drwx------ uucp uucp /dev/serial/locked
crw-??-??- uucp uucp /dev/serial/locked/ttyS1
Then the locking is achieved by mv of the device to the locking
directory. If the mv fails, then the device is unavailable.
Then programs that do not honour the locking scheme are still prevented
from interfering with any already running UUCICO.
Regards,
Andy