hz247bi@duc220.uni-duisburg.de (Bieniek) (07/16/90)
Hello, could someone be so nice and explain me the usage of the getfh systemcall which is available on machines running NFS-Kernels ? I know, it's a "read the funny source" Question, but I do not have access to BSD Kernel or Sun NFS sources. Thanks, Rainer -- +-----------------------+--------------------------------------------------+ | Rainer Bieniek | E-Mail: hz247bi@sun-hrz.uni-duisburg.de | | Wilhelmstr. 10 | rainer@blackbox.UUCP (Subnet only) | | 4100 Duisburg 11 | |
jik@athena.mit.edu (Jonathan I. Kamens) (07/17/90)
In article <1990Jul16.161053.4685@duc220.uni-duisburg.de>, hz247bi@duc220.uni-duisburg.de (Bieniek) writes: |> could someone be so nice and explain me the usage of the getfh |> systemcall which is available on machines running NFS-Kernels ? |> I know, it's a "read the funny source" Question, but I do not have |> access to BSD Kernel or Sun NFS sources. File access information between NFS servers and NFS clients is communicated with entities called "file handles"; When an NFS client kernel wants to access a file on an NFS server, it asks for the file handle for that file (doing a path look-up based on the file-handle of the NFS mount-point and the path from that mount-point to the file in question, I believe), and uses that file handle in subsequent communication with the NFS server. OK, so this doesn't explain to you what getfh() is for, since file handle usage would seem to be confined to the client and server kernels, not to user processes that need to make system calls. Well, when you go to mount an NFS filesystem, you have to have some way of telling the client kernel what the filesystem you want to mount is. The mount program makes a request to rpc.mountd on the server machine, specifying the name of the directory the client wants to mount. Rpc.mountd opens the file, and then does a getfd() on the file descriptor thus obtained; the kernel returns a file handle for the directory in question. Rpc.mountd then sends this back over the wire to the NFS client, which passes it to the client kernel in order to complete the mount. Therefore, the simple answer to your question is, "Rpc.mountd uses getfh() to get an initial file handle to give to clients who request NFS mounts." Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
kseshadr@quasar.intel.com (Kishore Seshadri) (07/17/90)
In article <1990Jul16.161053.4685@duc220.uni-duisburg.de>, hz247bi@duc220 (Bieniek) writes: > >Hello, >could someone be so nice and explain me the usage of the getfh >systemcall which is available on machines running NFS-Kernels ? >I know, it's a "read the funny source" Question, but I do not have >access to BSD Kernel or Sun NFS sources. > On SunOS, the new getfh (4.x) takes a pathname: int getfh(path, fh) char *path; fhandle_t *fh; The old getfh took a file descriptor, so getfh((char *)fd, fh) works where fd is a file descriptor returned by open(). Kishore Seshadri =============================================================================== Kishore Seshadri (Speaking only for myself) Intel Corp., Santa Clara, CA CSNET: kseshadr@mipos3.intel.com ARPA: kseshadr%mipos3.intel.com@relay.cs.net UUCP:{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!kseshadr
guy@auspex.auspex.com (Guy Harris) (07/19/90)
>The old getfh took a file descriptor, so > >getfh((char *)fd, fh) > >works where fd is a file descriptor returned by open(). Although this is, of course, 1) rather sleazy and 2) not intended to be supported indefinitely - there's a comment in the source code that says: * Also recognizes the old getfh() which takes a file * descriptor instead of a file name, and does the * right thing. This compatibility will go away in 5.0. * It goes away because if a file descriptor refers to * a file, there is no simple way to find its parent * directory. ("5.0", at this point, probably means "the next major release, which will be S5R4-based"), so you shouldn't actually pass file descriptors to "getfh()" - it's just there for binary compatibility.