cu/ecu through TCP/IP (plus ecu porting status)

[L. Hirschbiegel]

In article <1991May17.171141.27309 at chinet.chi.il.us> les at 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 at chinet.chi.il.us

Lothar Hirschbiegel
-- 
-----------------------------------------------
L. Hirschbiegel, AEG - A84, Frankfurt (Germany) 
email: unido!aega84!lh     tel: -49-69-66414316  
-----------------------------------------------