Re: mmaping on plan9? (was Re: [9fans] venti /plan9port mmapped

["Alyssa M via 9fans" <9fans@9fans.net>]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

On Friday, February 13, 2026, at 1:36 AM, Dan Cross wrote:
> Let me be blunt: the `mmap` interface, as specified in 4.2BSD and
implemented in a bunch of Unix and Unix-like systems, is atrocious.
Its roots come from a system that was radically different in design
than Unix, and its baroque design, with a bunch of operations
multiplexed onto a single call with 6 (!!) arguments, two of which are
bitmaps that interact in abstruse ways and one of which can radically
alter the semantics of the call, really shows. I believe that it __is__ possible to do better.
I'm definitely with you there.

What I'm trying to do is explore whether the standard read/write calls with a different implementation could make mmap redundant by using the combination of demand paging and copy-on-write to defer or elide I/O. This is not mmap, and not really memory mapping in the conventional sense either. But I think it can do the things an mmap user is looking for (so long as they're not looking for frame buffers or shared memory.) A successful implementation will not be detectably different from the traditional read/write calls except with respect to deferred or elided I/O.

 The key ideas are that the read (and write!) system calls associate buffer pages with a snapshot of the file data involved (which is then demand loaded - deferred), and altering memory pages breaks that association, and associates the altered pages with the swap file. Pages that are still associated with the file region they're being written to are not written (this is the eliding part). Fragments of pages are treated traditionally. The segment this happens in may be logically much larger even than the swap area - and not is pre-allocated, so pages are either allocated swap space on demand, or are associated with snapshots.

There's much more I could say, but I don't have it all working yet, and making it work at scale is probably another story.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-M2ad0abab705206e4d7351e45
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2839 bytes --]