Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!oliveb!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: touching devices through RFS Message-ID: <11162@sun.uucp> Date: Fri, 9-Jan-87 03:31:59 EST Article-I.D.: sun.11162 Posted: Fri Jan 9 03:31:59 1987 Date-Received: Fri, 9-Jan-87 20:57:15 EST References: <2086@brl-adm.ARPA> <1559@ulysses.homer.nj.att.com> <1617@ulysses.homer.nj.att.com> Sender: news@sun.uucp Lines: 23 Summary: Oh, really? Even "ioctl" arguments? > > 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")?