🚀 go-pugleaf

| From: davecb@yunexus.UUCP (David Collier-Brown)
|| henry@utzoo.uucp (Henry Spencer)
|| Gee, how could we ever have lived without that for two decades?  :-)
|| Maybe because we don't need it and it doesn't buy us very much?
| Very bluntly, Multics-style unification of the concept of a named file and
| a named memory segment is one of the things that was best left out of Unix.

I don't agree that Unix has really "lived without" that feature, or that
it was totally "left out" (though certainly it *was* left out in the
strong form in which it occurs in Multics).  Many, many, many Unix vendors
(essentially all those that provide paging instead of swapping) do the
moral equivalent of mapping (portions of) executable files into
(portions of) multiple process address spaces, with true faulting to the
file itself. 

| Now if you want to rethink it from scratch, and **design** it in, thats
| another story.

Very true.  This is a case where Unix has adopted the position it has
by slow accretion and not by careful forethought (or even rethought).
It is all very well to say that Unix can get 90% of the benefit for
10% of the cost by selectively implementing some but not all ways in
which files can be memory mapped, but this tradeoff has clearly not
been carefully thought out.

I'd say that *at* *least* the ability to page or swap into a filesystem
instead of a specially formatted "swap area" should have been included
in that 90% gotten for 10%.  Whether memory mapping of files visible to
users is more arguable, but I think it certainly isn't nearly as hard to
do as some implementation have made it in the past. 


In any event, it is I think clearly premature and too abrupt to
simply dismiss file mapping to memory (with whatever semantics)
as a frill not worth considering.  (Henry and/or David might agree
with this, but it seemed from their postings that they were
too eager to dismiss consideration of file mapping, either to
a never-worthwhile category or to an only-an-acedemic-issue-as-yet
category.)
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org