andchan@ccu.umanitoba.ca (Andrew Chan) (12/15/88)
I am wondering why no one has written a public domain version of the Sun PC-NFS. Wouldn't it be a nice thing to have? I actually heard that someone (at University of British Columbia?) had written a package that will turn a PC into a NFS file server. Apparently it was never released to the public? I am actually more interested in a **client version** than a server one. Are we running into legal problems here?
jas@proteon.com ("John A. Shriver") (12/17/88)
The lack of a public domain PC NFS has very little to do with the issues of NFS/RPC/UDP/IP/... 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. I have no idea what would happen if someone did the reverse engineering and then put the results in the public domain. Lawsuits? 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.)
phil@UMD5.UMD.EDU (Philip Shafer) (12/18/88)
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 modelsgeoff@eagle_snax.UUCP ( R.H. coast near the top) (12/19/88)
In article <8812161645.AA10438@monk.proteon.com> jas@proteon.com ("John A. Shriver") writes: >The lack of a public domain PC NFS has very little to do with the >issues of NFS/RPC/UDP/IP/... 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. > Actually, there are two ways to implement a redirector under (on top of?) DOS. [And no, I'm not giving away any valuable secrets: anybody with a copy of IBM's PC Watch or a good debugger could figure this out in a moment.] The first, employed by Locus and (by derivation) PC-NFS emulates the DOS system call interface itself by intercepting int21 and a bunch of additional hooks. A definition of this interface has been published in the DOS Technical Reference and other sources; what makes the task hard (and why people guard their implementations jealously) is the fact that the definition is incomplete (there are a couple of critical undocumented calls) and the semantics are inadequately described (e.g. under what circumstances does DOS zero out the rest of a buffer following an incomplete read?). The second way to build a redirector is to intercept the internal int2f multiplex interface used by DOS itself. This is the interface used by the Microsoft redirector for which they charge the big bucks: it has been successfully reverse-engineered, but since the interface is modified at major DOS releases any implementors will be kept busy just staying up to date. >I have no idea what would happen if someone did the reverse >engineering and then put the results in the public domain. Lawsuits? I don't see why there should be any lawsuit. However, the level of effort is such that a successful implementation would become a very valuable asset, and the lure of profit, etc. etc. In addition to PC-NFS, I know of three ongoing efforts to develop PC DOS NFS clients. One (Beame & Whiteside's BW-NFS) was discussed in this newgroup a few months back. The others are still under wraps. As the architect of PC-NFS, I wish them well, with just a touch of pity: after shipping PC-NFS for two and a half years, we are still encountering subtle nuances within DOS which we need to emulate. I know just how busy - and frustrated - they're all going to be! >Oh yes, it would not be hard to make a PC do NFS file service. stan@lbl-csam.arpa (See-Mong Tan) has done a nice job in developing a server at Lawrence Berkeley Laboratory, and as he mentioned in <1485@helios.ee.lbl.gov> LBL and Sun are discussing its possible distribution. >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.) Absolutely - give me a Sun 4/280 with a couple of Super Eagles any day :-) -- Geoff Arnold, Sun Microsystems Inc. +--------------------------------------+ PC Dist. Sys. Group (home of PC-NFS) |When you're fresh out of lawyers, you | UUCP: {hplabs,decwrl...}!sun!garnold |don't know how good it's going to feel| ARPA: garnold@sun.com +--------------------------------------+