On Wed, Feb 11, 2026 at 11:08 PM Alyssa M via 9fans <[email protected]> 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
