Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!cs.umn.edu!msi.umn.edu!math.fu-berlin.de!unido!aega84!tmcsys!lothar From: lothar@tmcsys.UUCP (L. Hirschbiegel) Newsgroups: comp.unix.sysv386 Subject: Re: cu/ecu through TCP/IP (plus ecu porting status) Message-ID: <377@tmcsys.UUCP> Date: 18 May 91 15:01:21 GMT References: <1060@aega84.UUCP> <1991May16.154418.24131@chinet.chi.il.us> <1061@aega84.UUCP> <1991May17.171141.27309@chinet.chi.il.us> Reply-To: lothar@tmcsys.UUCP (L. Hirschbiegel) Organization: Private Site Lines: 69 In article <1991May17.171141.27309@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > >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. Sorry: as far as I know this is simply not true. Anyway there is passing of different structs for other affected syscalls as open(), creat() lockf() and so on. You wouldn't deny they are working :-) ? And if there is some kind of xdr (or basically some hton* and n*toh) why should just ioctl() be left out? Makes no sense for me... >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. Hmmm, this can have many reasons. Dunno what didn't work with uucico, but cu is just needing the (shared) device and some Systems and Dialers file, whereas uucico would need some more shared directories over RFSnet. > >>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). C'mon, this is trivial. You even have to make sure your home directory is mounted on the local disk before trying to log in, don't ya :-) ? Thats just a simple "/etc/mount | cut -f 3 -d ' ' | grep your_RFS_resource". And giving unique names to all of the tty devices in a local RFSnet isn't THAT impossible. I've done it by appending the host name to the appropriate tty0[01] entry, so you can even identify the locking host very easy in case you need that. I did not say you just turn the key and have a perfect RFSnet with shared tty devices... >Second, uugetty doesn't remove its >lockfile. How can it - it's gone at the time it should be removed? You are right here. But there are some hundred reasons more besides problems with RFS not to use uugetty. >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). This is really strange. All I can say is that it worked here. Buggy RFS version? Configuration problem? >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. Do you expect race conditions or what? >Les Mikesell > les@chinet.chi.il.us Lothar Hirschbiegel -- ----------------------------------------------- L. Hirschbiegel, AEG - A84, Frankfurt (Germany) email: unido!aega84!lh tel: -49-69-66414316 -----------------------------------------------