Path: utzoo!mnetor!uunet!seismo!esosun!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.lans
Subject: Re: NFS vs RFS
Message-ID: <933@nusdhub.UUCP>
Date: 30 Mar 88 20:09:15 GMT
References: <4192@chinet.UUCP>
Distribution: na
Organization: National University, San Diego
Lines: 56

in article <4192@chinet.UUCP>, les@chinet.UUCP (Leslie Mikesell) says:
>>	The structures passed durring the above functions are difined
>>under the approprate command/token.  I don't see where it would be all
>>that though to swizle the bytes around if necessary.  Anybody who
>>needs the bytes swizeled will take that into account when they write
>>their driver just like for any other system/standard.
> 
> But my point was about passing ioctl()s to remote devices.  The type
> of struct passed to ioctl is *device dependent*.  How is a dissimilar
> remote machine going to prepare a canonical form of something known
> only to a different machine?  Or alternatively, how can the device

The RFS file system is a UNIQUE "device"

READ the above!  "The Structures passed durring the ABOVE FUNCTIONS
are _DEFINED_ under THE APPROPRATE COMMAND/TOKEN."
 [in this case DUIOCTL, DUFCNTL {etc} are RFS tokens]

	Since only certain things are DEFINED for RFS access [just
like ANY other device] there are only certain things passed....

	It works like this:

	The ORDER of the memory structure is juggled into a
pre defined patern defining the value of the first X bytes
depending on which command you are issueing.  [i.e. the
"common stuff" comes first, and then the rest of the bits
come in an otherwise-first-come-first-serve basis.]
	THAT means that anybody who uses the RFS stuff will
know that at least the first X bytes alwars mean <whatever>
the extra stuff is take-or leave.
	It is just like mounting a forign file system under the
file system switch.  If you want to do it, you figure out your
constant info, and work with it.

	Put in a simpler form:  Your kernel dosn't understand
TCP/IP, RFS, NFS, IPC, SNA, BSC, or anything else until you
install the drivers.  The driver translates the information.
That's what a driver is for.  There is no great mystery in to
packet translation.  Your system does it every day in a thousand
ways.

	Whe you [or whoever] writes the driver for RFS they
get all the fromats [including the header files for ioctl and
the like which in this case happen to be the SVR? version in
pure form] and say "This is the format to assert my information
on the media.  Only these bytes are required for my system, so
I'll have to ignore the rest on input and fake them on output"
what could be simpler?  It's been done a million times for
TCP/IP and others...

I still don't see your problem, and aparently neither do the
people implementing the drivers for the byte swizeled machines.


Rob.