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

[hiro <23hiro@gmail.com>]

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

i'm not sure i understand even the most abstract topic discussed here,
what's the advantage of logically organizing your data in size constrained
unnamed page tables as opposed to files in a named tree?

in the end you are assuming your memloads are not gonna be translated into
some message passing protocol underneath? are you sure you can treat all
your big data like one continuous memory region?

"The main benefits of mmap are reduced initial latency" -> latency from
where to where? what kind information are you transmitting in that
procedure?

what concrete problem are you trying to solve?


On Wed, Feb 11, 2026 at 4:34 AM Ori Bernstein <ori@eigenstate.org> wrote:

> On Tue, 10 Feb 2026 05:13:47 -0500
> "Alyssa M via 9fans" <9fans@9fans.net> wrote:
>
> > On Monday, February 09, 2026, at 3:24 PM, ron minnich wrote:
> > > as for mmap, there's already a defacto mmap happening for executables.
> They are not read into memory. In fact, the first instruction you run in a
> binary results in a page fault.
> > I thinking one could bring the same transparent/defacto memory mapping
> to read(2) and write(2), so the API need not change at all.
> 
> 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);
> 

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

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