On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote: Bill Joy imagined it, the prototype is in one the 4.x BSD releases. Sun (Joe Moran) actually implemented it first in any Unix variant. It's possible the concept existed in some other OS but I'm not aware of it.

On 8/17/2020 12:27 PM, Noel Chiappa wrote: [What follows verges on being COFF-ish]. mmap() is descended from TENEX's PMAP, which is a simplified descendant of the file/process memory integration provided by Multics. (Other antecedents I leave to more informed genealogists than I.) A Multics process had an address space made up of segments (files) which were paged (vs. swapped). Segments were what programs dealt with, paging was done to manage the physical resources of the system. TENEX simplified everything to pages, address spaces were composed by mapping pages of the address space to files. Programs operated on pages, which were also what the system used to manage memory. Files were described by page tables, address spaces were described by page tables, lots of symmetry around things of size 512 (9 bits) (page size, page table size, page-tables of page tables for long files). File size and file system system capacities were announced in pages. Very harmonious, but uniquely so. Multics was most definitely not portable due to its unique hardware constraints (Intel's 432 being an exception). TENEX only required paging support but was not portable from PDP-10s which were not keeping up with the world's movement to computers that were increasingly 4-bits shy of a word (i.e., not 36 bits). Many more considerations apply but to keep it only verging on COFF-ish will stop there -- going deeper would be best done in person with tankards of ale. TENEX systems were ARPA's workhorse systems in the 1970s, supporting numerous research programs and sites. The file/process memory integration was a valued capability among the community (though, honestly, it was one of these things everyone said should exist though few actually used directly). Even though DEC provided commercial support by adopting TENEX as TOPS-20 and selling 1000s of them (vs. the 10s of them made via BBN + PARC's MAXC), as the 70's progressed it was apparent that things were going to shift elsewhere. DEC was hesitant about further 36-bit development and UNIX's arrival provided an intellectual migration path for the community that commercial alternatives didn't. If only UNIX could just accumulate some of the capabilities expected in the ARPA world, like file/process memory integration (ironically, one of the Multics complexities from which UNIX had departed.) mmap() is a simplified, portable form of PMAP. It was written into the specifications for ARPA via Bill Joy as Larry McVoy and Noel Chiappa noted. It existed only as a specification for quite a while. First implementations were as a device-driver level function for things like frame-buffers for use by window systems and perhaps for other devices I'm not remembering at the moment. The general file/process memory integration aspect didn't happen prior to SunOS 4.0 though I seem to recall some special-case subsets being tried by other UNIX implementations and also more generally with Mach, I believe. The gestalt of file/process memory integration in 4.0 was very TENEX-like in how it was used in fork()/exec()/brk()/shared libraries. 4.0 differed from TENEX in being portable, launched on heterogeneous hardware (VAX, 68010 (Sun-2's), 68020 (Sun-3's), 386 (386i), SPARC (Sun-4) all except the VAX being actively supported Sun products at the time), and a general-networking view of how coherency should work (vs. a clustered-network such as TOPS-20's CFS.) (As a hysterical note, every release of (BSD-based) SunOS through 4.0 was always ported to the VAX as a portability check. It also provied us utility as a convenient way to quickly check for "but it works on the VAX" problems with new things gotten from UCB. Prior to 4.0, given that the BSD-based implementation basically tried to mimic a VAX internally, that wasn't too bad. But the VAXectomy that occurred in 4.0 made that much more daunting, and so the 4.0 VAX port was a pretty half-hearted attempt and the last new task for the 11/750 that faded deeper and deeper into the back of the lab over time.)