Newsgroups:
comp.os.linux.networking,comp.os.linux.misc,alt.linux.os,comp.os.linux.setup
From: vern@zebra.alphacdc.com (Vern Hoxie)
Subject: Re: Setting uugetty dialin on a RedHat Linux system
Organization: Denver, Colo.
Date: Wed, 3 Jul 1996 06:56:45 GMT
In article 31D4BBBA.66BDBA5A@iceonline.com,
vladimip@iceonline.com wrote:
>Hi,
>
>If you ever succesfully installed and configured uugetty
on
>your RedHat 3.0 system (not Slackware!), please send me:
>
>Your /etc/inittab
>Your /uugetty.ttyS<number>
>your favourite initialization modem string :)
>
>BTW, where do you store your uugetty.ttyS,number: in /etc
>or in /etc/defaults?
>
>All the documentation/man pages that came with uugetty is
very
>Slackware-oriented.
1. Forget the 'uugetty' as distributed with Slackware. Get my 'getty_em' for a simple application or use 'mgetty' by Gert Doering.
2. Forget the references in Serial Howto to the use of 'ttyS*' for incoming calls and 'cua*' for outgoing. Use 'ttyS*' for both.
3. Read the blurbs in my 'serial_suite.tgz' for information about usage and applications for the serial ports. It is available via ftp from 'scicom.alphacdc.com'. 'Getty_em' is also part of 'serial_suite'.
4. Incomplete blurb on serial port locking.
----------------------
Two different methods have been developed in an attempt to avoid having more than one process running on the same serial port at a time. One method was developed at AT&T by their uucico developers. The other was apparently developed at Berkely for the BSD system. This method was adopted by Sun and others including Linux.
Under the AT&T Unix, the problem was solved by using 'lockfiles'. These are simple files which contain the PID of the process using the port. The idea is that if the PID which created the lockfile is still active, other processes should wait. On Linux. these lockfiles are kept in the /var/lock/uucp directory. The names are 'LCK..ttyS0' etc. Under this system, only one device driver is used per port.
When a process wants to use the port, it first checks for a lockfile on the device it wants to use. If it find a file, it reads the PID recorded therein and checks if the process is still active or not. If the process still exists, the new process quits. If the old process has died, the lockfile is removed and a new one created.
The technique for creating lockfiles is to first create a temporary file complete with the PID written to it. This file is then linked to the desired 'LCK..ttySN' name. If some other process also wants this port and has created their own lockfile, our link will fail.
Under the BSD/Sun versions of Unix, two device drivers are provided for each port. Presumably one is for 'outgoing' calls and the other for 'incoming' calls. Under Linux, these drivers use the same coding and are identical except for a kernel lock. The operation of this locking method is very complicated and I am not sure I know all the side effects even though I have studied the code extensively.
First, it is necessary to understand that the 'open(2)' system call has a special flag when the file is a bolck special or character special device driver. This flag is 'O_NONBLOCK' or 'O_NDELAY'. With respect to serial devices, this means that a normal 'open' will block and not return until the Data Carrier Detect (DCD) line is asserted. If 'O_NONBLOCK' flag is included in the open command, the call will return immediately regardless of the status of the DCD line.
If the struct termios CLOCAL (see termios.blurb) option has been selected, the O_NONBLOCK flag is ignored.
In Linux, whenever the NORMAL (ttySN) device is neither open nor blocking on an open and an attempt is made to open the CALLOUT (cuaN) device, it will open immediately regardless of the presence or absence of the O_NOBLOCK flag. However if the NORMAL device is active or blocking on a read (see VMIN=1, VTIM=0 in 'termios.blurb'), an open on the CALLOUT device will fail and return an EBUSY error code.
On the other hand, if the CALLOUT device is open (O_NONBLOCK doesn't appear to a factor), an attempt to open the NORMAL driver will fail and return the EBUSY error code.
Thus, if you have a 'getty' listening on the 'incoming' line, it is impossible to place a call on the 'outgoing' driver. However, if you place your outgoing call on the 'incoming' driver, it will open and proceed normally. That is 'normally', if the 'getty' is smart enough to get off the line. The AT&T 'uugetty' (not the Linux uugetty) expect that the first characters received on incoming calls are either newlines or carriage returns. If any other characters are received, they are assumed to be outgoing characters and the 'getty' graciously exits.
I have been carrying on a discussion for the last couple of months about the need for 'cuaN and ttySN' drivers and so far I haven't received a convincing reason that there is an need for the 'cuaN' series. All the communication software provided with Linux, recognize the /var/lock/uucp lockfiles anyhow.
I hope that this clarifies the situation somewhat. As far as I am concerned, the only value the 'cuaN' and the 'Serial-HOWTO' is to confuse immigrants from DOS. I immigrated from AT&T SYSV and it confused me.
If you try to open a callout driver when the associated 'callin' driver is opened, the open returns EBUSY. If the normal driver is opened in blocking mode, and the callout driver is busy, the attempt to open will fail with EBUSY. However, if it opened in standard (blocking) mode, the open will block until the ports DCD line is asserted. For non-blocking mode and the cuaN port is inactive, the open will succeed immediately.
The problem is partly cultural and partly an attempt to state a complex situation in simply words.
The problem is "How to prevent incoming call and outgoing calls on a single port from colliding".
-------------------------
vern
--
Vernon C. Hoxie scicom!zebra!vern
3975 W. 29th Ave. vern@zebra.alphacdc.com
Denver, Colo., 80212 uucp: 303-455-2670 voice: 303-477-1780
Unix is what MSDOS will be when it grows up.