Accessing Serial Devices in Linux

[MindFu@er]

I have just installed the Linux operating system on my machine and I am totally new to this operating system due to which I don't have any idea to deal with the devices out of my machine or sometime internal device as well. I have created this thread to know that how can I access serial devices in Linux OS. I hope there are many linux professional who must be knowing about this thing. Please help me!

[Dolsy_bendal]

Like all devices on a UNIX system, you also access to serial devices through special files in the dev directory to /. There are two types of device files that have to do with serial drivers, and for each port, there is one device file of each type. Depending on the file from which you access it, the device will behave differently. We go to the differences in some detail, so you specific configuration details of serial devices better understand some. In practice, you will be there with kind of device files to do only get one, however, and in the future could be one of two Device files even disappear completely.

The most important of the two types of serial devices, the major number (major number) 4 Your device files are named ttyS0, ttyS1, etc. The second type has the major number 5, dial out applications using the ports provided for and used the device files cua0, cua1 etc. In the Unix world begins with each count, while lay people tend to, a zero is to begin. This counting method confuses many people because COM1: is not about the device / dev/ttyS1 corresponds to, but / dev/ttyS0! The interface COM2: same as / dev/ttyS1, etc. Anyone with something to do with PC hardware knows about, knows that the other interfaces such as COM3: never really been standardized and higher.

[Ernesto4]

Serial ports on which modems are connected must be able to receive data and send as both can be. Thus, it is not conflicts occur, device special files have been introduced, the so-called cua - or "callout" devices. Unfortunately, these have now proved itself problematic and more likely to be deprecated. The problem is this:

Linux allows (such as Unix, too), (device) file from multiple processes simultaneously to open a. This is very useful in point is for tty devices do not however make any sense, because it may happen that there are lawsuits against each other in the way are several. Fortunately, someone has figured out a mechanism, the process it enables one to open a device file noted before, if that file to another process was already occupied. This mechanism uses so-called lock files (lock files) and how it works: If a process opens a tty device, it first checks whether a particular file (the lock file) indicates that the device file name is similar. Is there such a file, the process takes, that the device you want other process used is one of. If the file does not exist, however, the process assumes that the device is free, then creates a lock file itself and reserves the tty device for themselves. There is one last clever trick to lock files so that the management of work. The PID of the process that created this file, the file is even written. Then we will go through the same.

[teena_pansare]

The lock file mechanism works perfectly in the system environment in which it unique directory for all files is a barrier and programs all know where this directory is located. If Linux was a long time not so. Only since the official launch of the Linux File System Standards (FSSTND) mechanism to work the lock file for tty devices in Linux without problems. Before, it was in some Linux distributions, in phases as many as four (if not more) different directories for lock files: / usr / spool / locks /, / var / spool / locks /, / var / lock / and / usr / lock /. It is clear in such confusion that could arise only chaos. Various processes opened at different places simultaneously lock files to control the individual tty devices actually thought were exclusive. These lock files were then useless.

Get out of this dilemma to find a way out, the cua devices were introduced. These device files used no more lock files to switch between programs with access to serial devices to solve the conflict, but left the decision to release the device to the kernel. Whenever a ttyS device was already open, should an attempt cua device to open its, produce an error that opened the program pointed out that the unit was already occupied. In the opposite case, ie when the device was already open cua and an attempt was made to ttyS to open the device, no error will be produced, but only the request to be blocked, ie, the opening process had to wait so long then until the from the other process was closed cua. This method works very well if one has only a single modem, the most time in the dial-in mode the up and down and a port belongs to the same device performs only. In environments where multiple programs run simultaneously in which the dialout device use do the same thing does not exist. This again would have to lock files are used, and we were just as smart as before!

[Luis234]

Only with the introduction of the Linux file system standard that would save the banks came in sight. He states that basically lock files are used and this in a unique directory should be stored as / var / lock. By convention, the names of all the lock files a special format. Thus, for example, the lock file for ttyS1 device called LCK .. ttyS1. The cua lock files for devices should be stored in this directory also, however, the use of these devices are discouraged.

The cua devices may be a while yet supported to ensure backward compatibility, but with time they will lose importance. If you are unsure, always use only ttyS devices and make sure that your system is really the Linux FSSTND used. At a minimum, programs that use any serial device, lock files in a single directory off their special. Most programs that allow devices to have to do with tty, offer the possibility of translation of its source files, the blocking list with a special compiler option must be chosen for. In some cases, this directory is in a variable called LOCKDIR Makefile or in a configuration file to specify the header. If you translate your software itself, it is best if you just stick to the FSSTND. For precompiled binaries, of which you do not know where to put the lock files, you can find the following:

binary strings file | grep lock

Is the displayed list does not agree with the rest of your system, you can still make do with a trick. Just try a symbolic link from the directory that is favored by the binary, the default directory / var / lock to create. This is not particularly elegant, but it works.