Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!sdcrdcf!sdcsmb!formal!darrelj From: darrelj@formal.sm.unisys.com (Darrel VanBuer) Newsgroups: comp.dcom.lans Subject: Re: NFS vs RFS (RFS ioctls) Message-ID: Date: 7 Apr 88 20:36:31 GMT References: <4456@chinet.UUCP> <1016@nusdhub.UUCP> <780@spdcc.COM> <10958@mimsy.UUCP> Reply-To: darrelj@formal.sm.unisys.com (Darrel VanBuer) Distribution: na Organization: Unisys Santa Monica Lines: 42 As someone outside this debate, I would like to offer a few comments (my experience is with Xerox Lisp machines which use a combination of PUP, XNS and TCP-FTP protocols for filing, plus I have looked at the possibility of implementing RPC/NFS in this environment). Both NFS and Xerox filing protocols are built on a remote procedure call layer (RPC and Courier, respectively). This RPC layer specifies the bit patterns sent through networking layers for any possible data object, including structures. In general, only the client and the server program know how to interpret the contents of the bit stream (was that word of zero bits the integer zero, a false boolean, the color BLUE from a discreet set a character string of nulls, or even the number 5 in the subrange 5..50). Different systems have been used to drive the generation of the bit stream. Sun RPC normally uses a "RPC compiler" to generate the necessary C code to do it as a preprocessor step in C compilation. Xerox Lisp does it by run-time interpretation of an extra argument which describes the format of the current call. Neither scheme depends on the operating system understanding the semantics of the call. I infer from the discussion that RFS tries to be transparent to the Unix I/O interface. If so, ioctl does present a problem. At the OS interface, you get only a pointer to a struct and its size. Between homogeneous systems, there are no problems. Between non-homogenous systems, the problems would be almost insurmountable. Besides the byte order problems, some machines don't even pack structures the same (int is different sizes, alignment rules may force holes, etc. To have the kernel reorder to some network standard would require the kernel knowing every ioctl you are willing to pass; having the server or client reorder would require knowing the struct layout rules and byte ordering for every potential remote partner. The alternatives which provide simple solutions to structure transmission (e.g. standard presentation ala RPC) would require changing the ioctl interface to include a structure descriptor or change the declarations of ioctl structures and the way they get filled in. While these are reasonable things to do, they are not transparent to existing code. Note that having a standard for transmitting calls over the network is important. Saying it does what RFS does now (presumably a write of the ioctl structure plus some control information) is not enough -- the first port to a popular machine with a different struct layout makes such a standard counterproductive if RFS has pretentions of utility in heterogeneous environments.