Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.lans
Subject: Re: NFS vs RFS (RFS ioctls)
Message-ID: <10958@mimsy.UUCP>
Date: 7 Apr 88 03:53:47 GMT
References: <4456@chinet.UUCP> <1016@nusdhub.UUCP> <780@spdcc.COM>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 23

>In article <1016@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert
>C. White Jr.) writes:
>>So, WHAT _IS_ the problem??

In article <780@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes:
>ioctl() calls on remote devices cannot be easily handled since
>the ioctl argument formed in user mode can be thought of as
>"opaque" to the local kernel, having meaning only between the
>user program and the server kernel.

Right.  Here is a concrete example:  I want to plug your SysV RFS
68000-based machine into my 4BSD Vax network, and I want to use a 4BSD
partition from the SysV machine.  To do this I need to do a DKIOWDINFO
IO control.  SysV does not *have* a DKIOWDINFO ioctl, or if it does, it
is certain to be different from that in 4.3+.  But RFS claims
transparent access to remote devices!

I could go add DKIOWDINFO to the SysV machine (assuming I had sources).
But what if it already had one, except that its version took one `int'
argument?  The 4.3+ DKIOWDINFO takes a 276-byte structure.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris