Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!mcsun!unido!aega84!lh
From: lh@aega84.UUCP (L. Hirschbiegel)
Newsgroups: comp.unix.sysv386
Subject: Re: cu/ecu through TCP/IP (plus ecu porting status)
Message-ID: <1061@aega84.UUCP>
Date: 17 May 91 10:37:43 GMT
References: <7525@spdcc.SPDCC.COM> <409@n4hgf.Mt-Park.GA.US> <1060@aega84.UUCP> <1991May16.154418.24131@chinet.chi.il.us>
Reply-To: lh@aega84.UUCP (L. Hirschbiegel)
Organization: AEG - A84, Frankfurt / West Germany
Lines: 40

In article <1991May16.154418.24131@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <1060@aega84.UUCP> lh@aega84.UUCP (L. Hirschbiegel) writes:
>
>You should note that this depends on the structs used by ioctl() being
>identical on the client and server machines, which is pretty unlikely
>among different CPU types, especially if one of them happens to be
>an Intel and the other isn't.  Also, things like lockfiles for the ports
>will be done wrong, although HDB uucp seems to use kernel locks on the
>device itself, which does work over RFS (so you should probably modify
>ecu to do that also if it doesn't already).
>
>Les Mikesell
>  les@chinet.chi.il.us

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). 
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.
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.
To conclude, we have used shared serial devices via RFS very extensively
with almost zero problems, but the question still remains: can it be
done with an RS6000? (Think this was the original posters equipment).
If there is no RFS for the beast the problem is void.

L. Hirschbiegel
-- 
====================================================================
L. Hirschbiegel, AEG Produktionsautomatisierung, Frankfurt (Germany)
unido!aega84!lh                                      -49-69-66414316
====================================================================