From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17419 invoked from network); 20 Jun 2022 04:50:20 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 20 Jun 2022 04:50:20 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C1B3940D83; Mon, 20 Jun 2022 14:50:14 +1000 (AEST) Received: from freefriends.org (freefriends.org [96.88.95.60]) by minnie.tuhs.org (Postfix) with ESMTPS id 7596D40D81 for ; Mon, 20 Jun 2022 14:50:10 +1000 (AEST) X-Envelope-From: arnold@skeeve.com Received: from freefriends.org (freefriends.org [96.88.95.60]) by freefriends.org (8.14.7/8.14.7) with ESMTP id 25K4o2QG023031 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 19 Jun 2022 22:50:03 -0600 Received: (from arnold@localhost) by freefriends.org (8.14.7/8.14.7/Submit) id 25K4o1Vv023015; Sun, 19 Jun 2022 22:50:01 -0600 From: arnold@skeeve.com Message-Id: <202206200450.25K4o1Vv023015@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: arnold set sender to arnold@skeeve.com using -f Date: Sun, 19 Jun 2022 22:50:01 -0600 To: tuhs@tuhs.org, norman@oclsc.org References: In-Reply-To: User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID-Hash: VWCN5LSMZ5UQ6Y37X23374V6UILI3NMW X-Message-ID-Hash: VWCN5LSMZ5UQ6Y37X23374V6UILI3NMW X-MailFrom: arnold@skeeve.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: RFS (was Re: Re: forgotten versions) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: RFS was not Peter's code. It was stateful, which had advantages and disadvantages. And, as someone else mentioned, if two systems were binary compatible, remote device access worked, including ioctls. IIRC Steve Rago ported Peter's code to System V Release 4, and publilshed a paper about it, but I don't think the code ever escaped AT&T. System V Release 4 sorta overdid the special file system thing; as I recall /dev/fd was done as a file system! FWIW, Arnold norman@oclsc.org (Norman Wilson) wrote: > I don't know the exact history of RFS a la System V, but I > don't think it was Peter Weinberger's stuff, and it certainly > wasn't his code. Nor his name: he called his first version > neta and his second netb (he knew it would be changing and > allowed for it in the name from the start). > > I don't remember us ever calling it RFS, or even remote > file systems, inside 1127; we called it network file systems > (never NFS because the Sun stuff existed by then). > > For those who don't know it, Peter's goal was quite different > from that of NFS. The idea behind NFS seems always to have > been to mount a remote file system as if it were local, with > a base assumption early on that everything was within the > same administrative domain so it was OK to make assumptions > about userids matching up, and running code as super-user. > Peter described his intent as `I want to be able to use your > disks, and that's a lot simpler if I don't have to get you > to add code to your kernel, or even to run a program as > super-user.' Hence the entirely-user-mode server program, > which could use super-user privileges to afford access as > any user if it had them, but also worked fine when run as > an ordinary user with only that user's file permissions. > We did in fact normally run it as super-user so each of > our 15 or so VAXes could see the file system tree on each > other, but we also occasionally did it otherwise. > > That was one reason device files worked as they did, accessing > the device on the server end rather than acting like a local > special file on the client: we didn't care about running > diskless clients, but we did occasionally care about accessing > a remote system's tape drive. > > Peter, being a self-described fan of cheap hacks, also wasn't > inclined to spend much time thinking about general abstractions; > in effect he just turned various existing kernel subroutines > (when applied to a network file system) into RPCs. The > structure of the file system switch was rather UNIX-specific, > reflecting that. > > That also means Peter's code was a bit ad-hoc and wonky in > places. He cleaned it up considerably between neta and netb, > and I did further cleanup later. I even had a go at a library > to isolate the network protocol from the server proper, converted > the netb server to use it, and made a few demo servers of my own > like one to read and write raw FILES-11 file systems--useful for > working with the console file system on the VAX 8800 series, > which was exported to the host as a block device--and a daemon > to allow a tar archive to be mounted as a read-only file system. > > In modern systems, you can do the same sort of things with FUSE, > and set up the same I-want-to-use-your-disks (or I want to get > at my own files from afar without privileges) scheme with sshfs. > I would be very surprised to learn that either of those borrowed > from their ancient cousins in Research UNIX; so far as I know > they're independent inventions. Either way I'm glad they exist. > > Norman Wilson > Toronto ON