Hardware manual

FAQ is at http://www.best.com/~cae/irqtune
13. Locking Out Others
13.1 Introduction
When you are using a serial port, you may want to prevent others from using it at the same time. However
there may be cases where you do want others to use it, such as sending you an important message if you are
using a text-terminal.
There are various ways of preventing others (or other processes) from using your serial port when you are
using it (locking). This should all happen automatically but it's important to know about this if it gives you
trouble. If a program is abnormally exited or the PC is abruptly turned off (by pulling the plug, etc.) your
serial port might wind up locked. Even if the lock remains, it's usually automatically removed when you want
to use the serial port again. But in rare cases it isn't. That's when you need to understand what happened.
One way to implement locking is to design the kernel to handle it but Linux thus far has shunned this solution
(with an exception involving the cua device which is now obsolete). Two solutions used by Linux is to:
create lock-files1.
modify the permissions and/or owners of devices such as /dev/ttyS22.
13.2 Lock-Files
If you use the new device-filesystem (devfs) then see the next section. A lock-file is simply a file created to
mean that a particular device is in use. They are kept in /var/lock. Formerly they were in
/usr/spool/uucp. Linux lock-files are usually named LCK..name, where name may be a device name,
a process id number, a device's major and minor numbers, or a UUCP site name. Most processes (an
exception is getty) create these locks so that they can have exclusive access to devices. For instance if you dial
out on your modem, some lockfiles will appear to tell other processes that someone else is using the modem.
In older versions (in the 1990s) there was usually only one lockfile per process. Lock files contain the PID of
the process that has locked the device. Note that if a process insists on using a device that is locked, it may
ignore the lockfile and use the device anyway. This is useful in sending a message to a text-terminal, etc.
When a program wants to use a serial port but finds it locked with lock-files it should check to see if the
lock-file's PID is still in use. If it's not it means that the lock is stale and it's OK to go ahead and use the port
anyway (after removing the stale lock-files). Unfortunately, there may be some programs that don't do this
and give up by telling you that a device is already in use when it really isn't.
If the lockfile only uses device names, the following problem could arise: If the same device has two different
names then two different processes could each use a different name for the same device. This results in
lockfiles with different names that actually are the same device. Formerly each physical serial port was known
by two different device names: ttyS0 and cua0. To solve this lockfile alias problem, 3 methods have been
used. It may be overkill since any one of these methods would have fixed the problem.
The lock checking software was made aware of ttyS vs. cua.1.
The device cua was deprecated2.
Additional locks were created which use unique device numbers instead of names.3.
Serial HOWTO
12.2 Higher Serial Throughput 54