Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!BU-CS.BU.EDU!bzs
From: bzs@BU-CS.BU.EDU
Newsgroups: comp.society.futures
Subject: Future at Berzerkeley
Message-ID: <8903290238.AA05889@bucsd.bu.edu>
Date: 29 Mar 89 02:38:20 GMT
References: <1300@auspex.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 67


From: auspex!guy@uunet.uu.net  (Guy Harris)
>...an "mmap" that lets you map files into your address space.)
>
>Now, CMU already has something of that general nature that runs on BSD
>systems, as I understand it (Andrew uses it, as I remember), so in that
>sense BSD will have it, even though it may not be on the tape you get
>from Berkeley. 

Interestingly Mach's file mapping only supports that transparency on
read operations, write() still has to go through the system call
interface so you get this asynchrony of being able to read a file as
if it were an array of bytes (or whatever) in memory but you then have
to do seek/write pairs on the underlying fd if you want to update it.

The reasoning (as I heard it) had to do with maintaining consistency
in a distributed environment, read consistency across machines is of
course trivial but write consistency requires real work.

Somehow I still felt that one didn't have mmap'ing if only that easy
case was solved, not sure why they couldn't mark pages read-only and
take the hit on modifies (and warn programmers that using write()
might be more efficient.)

You only have to take the hit once per page and only ("only!") inform
the other systems with the file open that page XYZ is modified (ie.
don't have to xfer the whole page, they may never need it, lazy
evaluation) and set the page invalid on the other systems and xfer it
if they try to access it (on a fault, or perhaps some more aggressive
algorithm.)

Oh what an evil web we weave when first we venture to transmit and
receive!

>It depends; if a version of AFS is made whose kernel-level functions
>plug into a VFS-type interface, it will be possible to plug it into an
>S5R4 system.  Does AFS run under an unmodified BSD?  If not, then the
>real question to ask is "how easy is it to modify BSD to support it vs.
>how easy is it to modify S5 to support it".

The last I heard AFS was being modified to respond to NFS requests
("oh, that was an NFS-oid mount request, better remember to speak NFS
to that guy.") Round and round.

>My personal guess, for what it's worth (which isn't a hell of a lot;
>from what I've seen, I don't put much stock in predictions of the future
>in this field), is that some research flavor of UNIX will continue to be
>popular in universities and other research institutions.  I don't know
>whether it'll be BSD, or Mach, or something else; I suspect it'll be
>less stable than S5-from-AT&T, as suggested by others, and that its
>relative lack of stability will be precisely one of those features that
>*makes* it popular - for instance, it'll be easier to get innovations
>onto the distribution tape.  It may be easier to get source for it,
>which may help as well.

I think the time has long passed for a completely non-proprietary
source source for a UNIXoid system. Back when machines were expensive
resources we had the sources but couldn't get enough downtime to
really hack. Now that a machine capable of running a respectable O/S
is, I dunno, like $3K (386+4MB+80MB disk), about the same as dumb
CRT's back then, the sources are slipping out of our
hands...unfortunate. It will change.

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.