andrew@hammer.TEK.COM (Andrew Klossner) (01/08/87)
[]
"When you open a remote file in RFS, the remote machine does
the open() and, provided you have the right permissions, all
works transparently. This works for special files as well as
regular ones."
What happens when the local machine executes an ioctl? Does the remote
machine also do an ioctl? If so, how does it know which of the values
in the structure parameter need to be rearranged because of
byte-ordering and structure alignment differences?
This is a real problem in our environment. We have a proprietary
remote FS running on both big-endian and little-endian machines. Bigs
can ioctl to bigs and littles can ioctl to littles, but the two cannot
meet without encoding knowledge of every ioctl into the RFS or
knowledge of the RFS into every device driver.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(tekecs!andrew.tektronix@csnet-relay) [ARPA]ekrell@ulysses.UUCP (01/08/87)
In article <2733@hammer.TEK.COM> andrew@hammer.TEK.COM (Andrew Klossner) writes: > >What happens when the local machine executes an ioctl? Does the remote >machine also do an ioctl? Yes. > If so, how does it know which of the values >in the structure parameter need to be rearranged because of >byte-ordering and structure alignment differences? RFS uses internally a canonical form to pass arguments back and forth between the server and the client machines. The caller converts its arguments into this canonical form and the callee converts this canonical form back into structures or whatever types are needed, making it independent of any byte-ordering or alignment requirements. -- Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
guy%gorodish@Sun.COM (Guy Harris) (01/09/87)
> What happens when the local machine executes an ioctl? Does the remote > machine also do an ioctl? If so, how does it know which of the values > in the structure parameter need to be rearranged because of > byte-ordering and structure alignment differences? Unless this is yet *another* thing added to the 3.1 "maintenance" release (would the AT&T-IS people please indicate whether something is true of the current S5R3 release or will be true when 3.1 comes out?), RFS doesn't handle this. As you point out, it requires somebody to translate every "ioctl" argument to a standard form when it goes over the net. Somewhere, either on the client or the server side, the XDR format (or its equivalent, although I think RFS uses XDR) for every possible "ioctl" argument needs to be stored.
guy%gorodish@Sun.COM (Guy Harris) (01/09/87)
> > If so, how does it know which of the values > >in the structure parameter need to be rearranged because of > >byte-ordering and structure alignment differences? > > RFS uses internally a canonical form to pass arguments back and forth between > the server and the client machines. The caller converts its arguments into > this canonical form and the callee converts this canonical form back into > structures or whatever types are needed, making it independent of any > byte-ordering or alignment requirements. OK, a few questions: how do the caller and callee know what the rules for converting every possible "ioctl" argument into its canonical form are? Is this stored somewhere in the kernels on both sides? What happens if the server has a device that the vendor of the client has never heard of, and it supports special "ioctl"s? Does the information that the server has about this device get sent to the client somehow? As I said earlier, this is a hard problem. None of the RFS code I've seen solves it. Did this appear in a later version, or (as I suspect) does RFS just punt on this problem and just send the "ioctl" argument over in raw form (meaning that it will not work correctly if the representations are different on the different macines, but will probably do so by acting peculiarly, NOT by giving an error to the guy who issues the "ioctl")?
ekrell@ulysses.homer.nj.att.com (Eduardo Krell) (01/09/87)
I was mistaken in my impression that ioctl's go thru the canonical form code.
They don't in SVR3 but as SVR3 is ported to different architectures, they will
probably have to do it in some future release.
--
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrellgwyn@brl-smoke.ARPA (Doug Gwyn ) (01/09/87)
In article <1617@ulysses.homer.nj.att.com> ekrell@ulysses.UUCP (Eduardo Krell) writes: >> If so, how does it know which of the values >>in the structure parameter need to be rearranged because of >>byte-ordering and structure alignment differences? > >RFS uses internally a canonical form to pass arguments back and forth between >the server and the client machines. The caller converts its arguments into this >canonical form and the callee converts this canonical form back into structures >or whatever types are needed, making it independent of any byte-ordering or >alignment requirements. First, thanks for providing helpful information. It's appreciated. Second, there would seem to still be a problem with ioctls, since the third argument to an ioctl is either an int or a struct pointer; the int is no problem but how in the world is the struct pointer dealt with? a) Is a remote copy-in/copy-out done? (e.g. for a struct termio in a TC[GS]ET* ioctl) b) What about the case when the kernel doesn't know about the internals of the particular structure used by the specific ioctl command code? (e.g., when accessing a remote device special file such as a frame buffer interface, when the local system was unaware of the possibility of the remote heterogeneous system supporting such a device) It seems to me that such data structures would have to be self- describing in the general case. Of course any that are universal (such as struct termio) could be mapped correctly on each end since each system knows their structure. P.S. This ioctl-over-network issue keeps coming up and getting in the way of standardizing ioctls in IEEE 1003 (POSIX).