Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!ucbvax!UMD5.UMD.EDU!phil From: phil@UMD5.UMD.EDU (Philip Shafer) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: public domain support for Sun NFS standard Message-ID: <8812171633.AA15227@umd5.UMD.EDU> Date: 17 Dec 88 16:33:25 GMT References: <8812161645.AA10438@monk.proteon.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 133 Hi folks, [ Some Background: I have worked for the past year and a half and am working (for 21 more days) for the University of Maryland on a grant from IBM to produce product level TCP/IP code. We, like most, began with the MIT code, wasted a lot of time deciding it was worthless, and then did a complete bottom-up rewrite. The code we deliver to IBM contains a stack of unloadable device-driver and OS-extension TSRs, all the (rewritten) applications from our previous release, an NFS client, a multi-session telnet, a programmer toolkit, and oodles of fun-loving documentation. Of course, whether IBM decides to bring this to market is not a decision I (or the University of Maryland) will make. The code is (sadly) copyright IBM, the following attitude is obvious not. :-) ] [ I speak neither for IBM, nor the University of Maryland, nor for my group, but only for myself, sharing my personal views about my works with my fellow Usenet readers. (thick coat of lawyer fodder) ] > The lack of a public domain ... of NFS/RPC/UDP/IP/... Try the sunrpc3.9 sources on for size, available from your neighborhood archive server (eg, uunet.uu.net). About a meg of client and server RPC and XDR library source, along with source to the portmap daemon, the rpcgen protocol compiler and protocol descriptions of NFS, MOUNT, and other interesting tidbits. Redistributable as part of a product. Written with a simple, extensible, slow, and memory intensive attitude, but it can be re-tooled to the DOS environment. > It has to do with the fact that the > interface to the MS-DOS redirector is essentially a highly-guarded > trade secret of Microsoft, available only if you sign up as a > MS-Networks OEM. This is not cheap, last I knew you had to pay by the > year. There are people who have sucessfully reverse-engineered this > interface (eg. Locus), but they consider it highly valuable > information, and also sell it for a pretty penny. The thought of delving that deep into the bowels of DOS file I/O still warps my mind. My heart really goes out to the families of anyone thinking of attempting this. Fortunately for my surviving family members, IBM delivered to us (after a nine-month wait) the OCO-classified- proprietary-top-notch-file-level redirector used in IBM's ECF product (one of my prerequisites for starting this madness). > I have no idea what would happen if someone did the reverse > engineering and then put the results in the public domain. Lawsuits? Doubt it. Wouldn't Microsoft or IBM be suing Locus if this were the case? > Oh yes, it would not be hard to make a PC do NFS file service. > Unfortunately, a PC, it's BIOS, and DOS offer pretty abysmal file > performance, so it would not be a good file server. (Interrupts off > during disk I/O does not help the NFS side of things.) I take it that you are refering to the fact the BIOS busy waits for disk/diskette command completion. Interrupts are on, but the PC is useless (as always?). This wouldn't be a problem as one would (hopefully) want to re-write the DOS file system so as to incorporate NFS file attributes (or are we writing a server for only one client?) and make a disk device driver (which would particpate in some multi-tasking scheme) would certainly be a step along the path. Then again, I'm not quite clear on why would you want a PC for an NFS file server anyway. Sounds like the worst of both worlds. If any one cares, I've seen a piece of (presumably) PUBLIC DOMAIN code for a user level (as opposed to kernel level) NFS daemon from Mark Shand of unsw.oz (Volume 15 Issue 1, available from your nearest comp.sources.unix archive as unfsd/Part*). It uses the sunrpc3.9 stuff as well, impliments readonly functionality, but seems portable (with the exception of the info he stuffs into the file handle). The largest problems I've had are (in order): 1 Microsoft compilers/development tools (don't get me started here) 2 debugging in a TSR environment where a good assembly level debugger is your only hope 3 getting reasonable code in as tight a space as possible in an environment where memory is *the* critical resource (see #1) 4 getting performance to an acceptable level my ongoing task (better, faster, bigger, better, smaller, slower, etc ) While I'm here... > Date: Fri, 16 Dec 88 11:41:04 EST > From: root%snowhite.cis.uoguelph.ca@cornellc.cit.cornell.edu > To: pcip@udel.edu > Subject: Public Domain NFS > Message-Id: <8812161212.aa12957@Louie.UDEL.EDU> > I agree that it would be a very useful item. I currently have a non-Sun > implementation of NFS Version 2 mostly written, that is intended to go > in a Berkeley Unix kernel arround a vnode layer. {I am just starting the > plug it into the kernel part, and this will take several months..} Again the sunrpc3.9 sources take care of the protocol pieces. All the programmer must do is deal with DOS (the 'tooth-pulling'ly painful stuff). > If there is someone out there that is a DOS wizard and keen enough to try > to incorporate it into a freely available TCP/IP package, they are more > than welcome to the code. The only currently available release with which I have any experience with is the MIT code. The thought of moving this to a TSR turns my stomach. Again, our code is a complete, bottom-up re-write. This is not to say that it cannot be done (the hardy have done it before), it just turns my stomach (you can see that the DOS world has had an adverse effect on my stomach). Again, this is not the hard part; dealing with DOS is. > - I don't know how you catch the DOS BIOS calls on the filesystem? BIOS would be too low level for NFS; perhaps for RVD or ND ... > { Not being a DOS wiz, my best guess is that you revector the 21H interrupt > and then filter out the requests on the net disks, but...} If only life were so easy. The horror stories I've heard, told, and had to deal with (jeez, I sound like my grandpa) would fill a book. > Any Heroes?? None here. Best of luck to any brave souls who attempt this, Philip "former hero?" Shafer P.S: Sorry, this turned out a little like scream therapy; hope it helps somebody, frightens the weak of will away, etc. P.P.S: IBM is a (tm) of guess who? Microsoft is undoubtably a (tm) of Microsoft, NFS and PCNFS are (tm) of SMI, phil is probably (tm) somebody. phil@umd5.umd.edu uunet!umd5.umd.edu!phil 301-454-2946 Hobbes: How come we play war and not peace? Calvin: Too few role models