mbr@THEORY.LCS.MIT.EDU (04/22/87)
I can see two totally different ways of implementing NFS in BSD. The "clean" way is to have *all* filesystem abstractions (including directories) be fully supported by the kernel (this was never the case in older Unixes). Library routines for things like opendir() and scandir() will use system calls instead of reading directory files, but no other library routines will change. The interface to NFS will be entirely in the kernel, and you will only have to relink everything once. Of course, you won't be able to take a binary to a vanilla BSD system and expect it to work, since it will use nonexistent system calls. But you'll be able to take it to any other system that supports the same system calls, even if it uses a different NFS implementation (or doesn't support NFS at all). The "dirty" way is to put all of the NFS code into library routines. System calls like open() will no longer be stub procedures that do the appropriate chmk; they will now contain code to trap and handle remote file operations. This method requires no kernel changes, but binaries will get a lot bigger, will become dependent on the particular NFS implementation in use, and will not be portable between machines that use different NFS implementations. A quick examination of the sources for Sun Unix 3.2 indicates that Sun has integrated NFS into BSD the "clean" way (correct me if I'm wrong). I've heard rumors that other NFS implementations are done the "dirty" way; does anyone have information about specific implementations? (I'm particularly interested in Mt. Xinu 4.3+NFS and Ultrix 2.0.) Finally, are the new system calls supported in Sun Unix becoming standard for BSD and derived sytems, even for those that don't have NFS? Thanks, Mark Reinhold Theory of Computation Group mbr@theory.lcs.mit.edu MIT Laboratory for Computer Science (617)-253-3037
ed@mtxinu.UUCP (Ed Gould) (04/25/87)
In article <7044@brl-adm.ARPA> mbr@THEORY.LCS.MIT.EDU (Mark Reinhold) writes: >I can see two totally different ways of implementing NFS in BSD. The "clean" >way is to have *all* filesystem abstractions (including directories) be fully >supported by the kernel (this was never the case in older Unixes). Library >routines for things like opendir() and scandir() will use system calls instead >of reading directory files, but no other library routines will change. The >interface to NFS will be entirely in the kernel, and you will only have to >relink everything once. Of course, you won't be able to take a binary to a >vanilla BSD system and expect it to work, since it will use nonexistent system >calls. But you'll be able to take it to any other system that supports the >same system calls, even if it uses a different NFS implementation (or doesn't >support NFS at all). > >The "dirty" way is to put all of the NFS code into library routines. It's possible to do the client-side of NFS in libraries, but the server side still needs to be a separate process. Sun sells a user-level NFS server package for this purpose. Implementing client-NFS at user- level is *extremely* inefficient, and probably requires breaking even more Unix semantics that does the kernel-based client implementation. >A quick examination of the sources for Sun Unix 3.2 indicates that Sun has >integrated NFS into BSD the "clean" way (correct me if I'm wrong). I've heard >rumors that other NFS implementations are done the "dirty" way; does anyone >have information about specific implementations? (I'm particularly interested >in Mt. Xinu 4.3+NFS and Ultrix 2.0.) All of the vendors I know of, including Sun, ourselves, DEC, and many others, are using kernel-based implementations. A few vendors started out using the user-level server (and no client implementation at all) as a feasibility demonstration. >Finally, are the new system calls >supported in Sun Unix becoming standard for BSD and derived sytems, even for >those that don't have NFS? All of our systems contain the new system calls, whether NFS functionality is included or not. We've also modified our library routines to detect that the new syscalls are missing, so that they'll run on otherwise- unmodified 4.3BSD systems. They may not work on Ultrix or other systems, though, because those systems may have used the same syscall numbers in other ways. Compatability at the library interface is maintained, but binary compatibility between divergent systems is not feasible in the long run. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."