Newsgroups: comp.unix.sysv386
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: cu/ecu through TCP/IP (plus ecu porting status)
Message-ID: <1991May17.171141.27309@chinet.chi.il.us>
Organization: Chinet - Chicago Public Access UNIX
References: <1060@aega84.UUCP> <1991May16.154418.24131@chinet.chi.il.us> <1061@aega84.UUCP>
Date: Fri, 17 May 1991 17:11:41 GMT

In article <1061@aega84.UUCP> lh@aega84.UUCP (L. Hirschbiegel) writes:

>Our RFS server is of course the same type of machine (all Compaqs)
>running the identical os version.
>But anyway: the structs used by the ioctl's should never be dependend
>on the type of cpu - as long as it is all SysV.3 or SysV.4 (and this
>IS in fact the limiting factor for RFS:-). I didn't find any differences
>in struct termio (which is obviously used here) depending on the
>version of SysV. Furthermore is it VERY unlikely you wouldn't find
>TCGETA and TCSETA in any version of SysV, and thats what ecu is actually
>using (and maybe TCSBRK but thats quite easy to avoid). 

RFS passes ioctl() structs in straight binary.  That means that differences
in byte ordering and field padding will affect operation even though
the termio.h files say the same things.  For example, I have 3B2's
and 386's RFSed together both running AT&T SysVr3.2 and a program on one
cannot ioctl() the devices on the other.  In fact, I haven't been able to
get uucico to work over RFS to a remote device on an identical machine,
although cu will do it on the 386's.

>Regarding lockfiles: no problem here. What could prevent you from
>sharing /usr/spool/locks all over the RFSnet?? As long as the usual
>lockfile format is used I wouldn't expect any fighting for devices.

Several problems.  First you need a unique name for every device
(shared or not) on the net that uses lockfiles, and you have to
make sure that the RFS link is up before you start any of the processes
that use them (like uugetty).  Second, uugetty doesn't remove its
lockfile. How can it - it's gone at the time it should be removed?
So programs that use lockfiles to contend with uugetty check to
see if the locking program is still running by sending signal 0
to the process and checking the status returned from kill().  If
the process is actually on another machine, kill() isn't going to
find it and the program will assume the lockfile is invalid.  The
correct approach here is to use kernel locks since they work over
RFS.  Even on local devices it is the best approach - I've seen
uucico's debug output indicate that it succeeded in obtaining
a lockfile but still failed to get the kernel lock (which really
indicates that the lockfile scheme didn't work).

>Even then I did some (admittedly quick n'dirty:-) solutions by wrapping
>the application into a shell script which creates some locks prior to
>accessing the device.

I'm pretty sure it isn't possible to do locks right in a shell script.
Creating a tmp file and using /etc/link to attempt to rename it to
the agreed-upon lockfile name is OK if it works, but you can never
safely test or remove an existing file.   Some version of ln might
do what you want, but SysVr3 removes the target before attempting the
new link. 

Les Mikesell
  les@chinet.chi.il.us