madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) (08/02/87)
In article <389@louie.udel.EDU> galvin@UDEL.EDU (James M Galvin) writes: >From: Paul Congdon <ptc@hpindda.hp.com> >> Why doesn't someone just post the source.... It can't be all that big. >> I have seen several postings (part1...partn) that have made it through >> the Net. Go for it! > >The compressed tar file on our machine is 1/2 meg. The uncompressed tar >file is almost 1 meg. That is a LOT of stuff to be mailing around. Do >we really want that? That is why I didn't post it right away. At our site it's not that important that we not mail around megabytes of stuff (although I suspect the powers that be will be looking for me shortly due to the multimegabytes of outgoing mail I've had recently), but elsewhere things are different. Why should we send this huge amount of stuff to machines all over the place when you can have those that want it come directly? It's a pain, but if you want the stuff bad enough, you'll do it. Anyway, the tar version is slightly larger than the shar'ed version (why? dunno). The full shar'ed version is approx 410K on my machine, which is some 5 times as large as ARPA mail will accept and nearly 10 times as large as most UUCP's will. Anyway, thanx to everyone who is taking over distribution of that. I really don't have the time. There are a few requests that I am going to try to take care of, but if possible please look for it in one of the libraries. I'm only around on weekends and I really don't have the time to send out seven or eight pieces of mail to each requestor (alas, I haven't mechanized the process yet). I would have put it somewhere to allow anonymous FTPing, but I don't have the power to do it (yet :-) and those that do don't live my hours. How is the port going? Any problems? I'm going to try it myself as soon as I manage to find the money to buy the MINIX code. Things are tight for students, you know :-). I was impressed to find out that postings have moved from mostly bug fixes to "what next" stuff. Well, I have some thoughts about that. To you people working on an NFS: Once you get TCP/IP going (it's not really that tough to get it running on different devices than ethernet, you know -- look at the 3com.c file -- so you could set it up via serial or [better] parallel) and you want to look at NFS, keep some things in mind. 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. I realize making a robust NFS is quite an undertaking but you have resources to draw upon that Sun did not when designing their NFS. Besides, it's great practice. When I manage to get hold of MINIX I'm going to use it as a guideline to a complete rewrite -- I want it to run on a 386 with REAL memory management and speed, and I think that building it myself would be a hell of a challenge. On a final note, my thanx to Andy for a fantastic book. I haven't tried the programs yet, but the book is well worth the money. It's one of the best books on OS building I've ever read! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Jim Frost * The Madd Hacker | UUCP: ..!harvard!bu-cs!bucsb!madd H H | ARPA: madd@bucsb.bu.edu H-C-C-OH <- heehee +---------+---------------------------------- H H | "We are strangers in a world we never made"
gnu@hoptoad.uucp (John Gilmore) (08/03/87)
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.