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

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

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

On Wednesday, February 11, 2026, at 10:01 AM, hiro wrote:
> what concrete problem are you trying to solve?
Making software simpler to write, I think. 
People have expressed an interest in bringing something like mmap to Plan 9. I'm wondering whether memory mapping could be done as an implementation matter, never visible through the API - much as executables have been demand-paged since antiquity. Uses of mmap(2) and msync(2) could be replaced with read(2) and write(2) that sometimes use memory mapping as part of their implementation. read would memory map a copy-on-write snapshot of the requested data. write would write  back only the parts that have changed. It's not the same as mmap, but it might be preferable.

On Wednesday, February 11, 2026, at 1:44 AM, Ron Minnich wrote:
> It's certainly not as simple as your one liner above :-)
Certainly true! Well there's a lot of history to learn from. Plan 9 has the benefit of being simpler, so it might be easier.

(I'm trying to implement this on my hobby OS at the moment - hence my interest, but it's not derived from Plan 9 (or anything else for that matter), so I don't talk about it much.)
I think the use cases are perhaps relatively specialised, so doing this in a special segment type in an optional driver might be fine.

On Wednesday, February 11, 2026, at 3:21 AM, Ori Bernstein wrote:
> That gets... interesting, from an FS semantics point of view.
What does this code print? Does it change with buffer sizes?
        fd = open("x", ORDWR);
        pwrite(fd, "foo", 4, 0);
        read(fd, buf, 4);
        pwrite(fd, "bar", 4, 0);
        print("%s\n", buf);
It must print "foo"!
In practice it wouldn't memory map a partial page like this anyway, but the result would be the same with a larger example.

On Wednesday, January 07, 2026, at 4:41 PM, ori wrote:
> The cached version of the page is dirty, so the OS will
eventually need to flush it back with a 9p Twrite; Let's
assume that before this happens, the network goes down.

How do you communicate the error with userspace?
I think the I/O really needs to not fail:
I've recently been building aa9fs, which sits between a remote file server and a mount point.
When the remote server goes down aa9fs automatically reconnects, and reestablishes the fids. The clients are blocked until the server comes back up, so they're never aware of the outage. If I get it into a decent state I'll share it.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-M62fa796f70106e96ce450b3c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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