From: barrett@pamsrc.enet.dec.com (Keith Barrett) Subject: Re: The great serial device naming controversy.... Date: Fri, 28 May 1993 14:56:55 GMT
>The problem with doing this is that it gives two handles available to the
>same serial port--which in it self is not bad-- but often the lockfile names
>are based on the serial port name, and it is REALLY bad to have the possibility
>of two ways to get to a serial port with two different lock files!!
I don't agree with this statement. While it would normally be true,
remember that we're already talking about two different devices:
/dev/ttyS and /dev/cua (with /dev/modem pointing to /dev/cua). There is
no real problem until you get into bi-modem usage of a serial port because
that's the senerio where both devices are inuse (otherwise, just
stick with one). In a normal system, uugetty/getty would normally be the
ONLY program trying to use /dev/ttyS -- all others would be using /dev/cua.
If /dev/ttyS is inuse, then /dev/cua does (or should) return a busy error.
That being the case, then the only problem "area" becomes the getty/uugetty
program, because it could open the /dev/ttyS device while /dev/cua is
inuse (because carrier is present and the open wouldn't block).
This is not a problem however.
The current getty_ps program already supports looking at TWO lock files.
If you use /dev/modem as a generic pointer, and reference it in your kermit
and uucp config files, then uugetty/getty can be configured to look at both
LCK..ttyS and LCK..modem before assuming the device is free. It doesn't
matter that programs which use only /dev/modem don't do this, because they'd
error out. Even if they didn't, uugetty/getty could easily be changed to
create both LCK files and nullify the problem.
This setup works perfectly on my system, and is the sugeested setup according
to the uucp and getty_ps text files, so it's already in practice.
Keith Barrett (\___/)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ == \---/
| Comments not represent- | barrett@pamsrc.enet.dec.com | ( ) =(|)
| itive of any employer. | Linux: You're not dealing with AT&T | ][ __|__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /@@@@\ /@@@@@\