Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!rutgers!ames!amdcad!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.os.minix
Subject: Re: TCP/IP code and NFS ports
Message-ID: <2610@hoptoad.uucp>
Date: Sun, 2-Aug-87 20:57:02 EDT
Article-I.D.: hoptoad.2610
Posted: Sun Aug  2 20:57:02 1987
Date-Received: Mon, 3-Aug-87 03:46:34 EDT
References: <389@louie.udel.EDU> <1074@bucsb.bu.edu.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 27

madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) wrote:
>                                                         It is not that
> difficult in practice to implement an NFS.  My class last semester did
> it for a project, although we did it outside of the kernel.  It's much
> easier to do it if you have similar machines -- we run all kinds of
> machines here and the return structures from stat() and such are a
> pain to implement in that case.  Why not build it from the ground up?
> Unless you're thinking of connecting to a Sun system or something,
> you'll be able to do it.

The whole point of writing an NFS is so you can talk to all the other
systems that run NFS.  If you just want a remote Minix file system,
that wouldn't talk to anything except Minix systems, don't call it NFS.
The way Jack is laying it out, it wouldn't even talk to Atari ST Minix
systems, if it passes binary "struct stat"s and such around.

There is already a public domain remote file system like this, called
"RFS" (not the AT&T product, but something done by Todd Brunhoff at U.
of Denver and Tektronix, and posted to mod.sources).  It's set up as
kernel hooks for Unix, but could probably be ported to FS hooks in
Minix.  A later version was also posted to net.sources in March 1986.

I think it'd be foolish to do your own remote file system protocol at
this point; why cut yourself off from the rest of the world?
-- 
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu	     gnu@postgres.berkeley.edu
Alt.all: the alternative radio of the Usenet.