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

[Dan Cross <crossd@gmail.com>]

On Wed, Feb 11, 2026 at 11:08 PM Alyssa M via 9fans <9fans@9fans.net> wrote:
> 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.

I don't understand that.  If the interface doesn't change, how is it simpler?

> 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.

The problem is, those aren't the right analogues for the file
metaphor.  `mmap` is closer to `open` than to `read`; `msync` is a
flush operation (that doesn't really exist as an independent syscall
on plan9, but is kinda sorta like close followed by an open in a way),
and `memmove` subsumes both `read` and `write`.

You _could_ build some kind of `read`/`write` looking interface that
wrapped around a region of mapped memory, but I don't see how that
would buy you very much; the reason one usually wants something like
`mmap` is one of two things: 1) to map resources from, say, a hardware
device into an address space; things like the frame buffer of a
display adapter, for example, or registers of some device in MMIO
space (whether that's a good idea or not is another matter). The other
is to map the contents of a file into an address space, so that you
can treat them like memory, without first reading them from an actual
file. This is useful for large but sparse read-only data files: I
don't need to read the entire thing into physical memory; for that
matter if may not even fit into physical memory. But if I mmap it, and
just copy the bits I need, then those can be faulted into the address
space on demand. An alternative might be allocating a buffer in my
program, seek'ing to wherever in the file I want to read the data,
reading, and then using. But let's be honest; that's a pain. It's
appropriate pain if I'm doing something like building a DBMS (see the
CMU paper I linked to before), but if my data set is basically
read-only, I don't care about the occasional latency spike as
something is faulted in, and my locality is sufficiently good that
those will be amortized into nothingness anyway, then `mmap` isn't a
bad way to do the thing (particularly with the external pager sort of
thing Ron was suggesting). As pointed out, Plan 9 _already_ uses
demand paging of mapped segments to load executables today: this isn't
particularly new.

But if I try to shoehorn all of that into open/close/read/write, I
don't see what that buys me. The whole point is to be able to avoid
that interface for things that I can reasonably treat like "memory";
if I'm just going to do that, but wrapped in open/close/read/write
anyway, then what does it buy me? Consider the "big data file" case:
I'm back to doing all of the manual buffer management and IO myself
anyway; I may as well just open/seek/read.

        - Dan C.


> 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 / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-Md40d34fc37ba55c9a7c3a403
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription