From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 30 Jul 2008 09:36:13 -0700
From: "Roman V. Shaposhnik" <rvs@sun.com>
In-reply-to: <20080729162834.GC31092@satori.no-ip.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <1217435773.5036.129.camel@goose.sun.com>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <20080717142135.539A31E8C1C@holo.morphisms.net>
	<20080729085214.GA3072@nibiru.local>
	<20080729162834.GC31092@satori.no-ip.org>
Subject: Re: [9fans] mmap
Topicbox-Message-UUID: f68390e6-ead3-11e9-9d60-3106f5b1d025

On Tue, 2008-07-29 at 12:28 -0400, Venkatesh Srinivas wrote:
> As far as interfaces go, mmap() is pretty tragic - the underlying
> translation structures can express more interesting things, some of
> which are even worth doing.

I can't agree more. The way I look at it is that mmap() seems to
be the answer but nobody ever bothered to ask the question it is
supposed to answer.

> In a system like Plan 9, where your file servers are on the other side
> of a 9P link, this mmap thing seems dubious. If what you want is the
> convenience that you get from having all the bytes in memory, reading
> them all in wouldn't be too hard. mmap()s magic really arises when you
> have a page-cache-like-thing.

As Russ, quite rightfully, pointed out: mmap() means different things
to different people. The tragic part is, that it tries to do lots of
things but it doesn't do anything particularly well. Personally, my
experience of trying to use mmap() as a useful abstraction for the
CPU's MMU was the last straw. It can't do even that reliably
and in a portable fashion. Not to digress, but I was even more surprised
to learn that there's not a single API on UNIX that can:
    http://thread.gmane.org/gmane.os.netbsd.devel.kernel/6392/focus=6457

So, what mmap() (the way it is done on UNIX) is good for? Here's my
personal list. Feel free to add (and suggest alternatives on systems
lacking mmap() such as Plan9):
   * a *lazy* way of handling highly irregular I/O over large files.
     Cases, where you can't really tell which parts of the file are
     going to be needed. The best example here is mmap() on exec.
     You don't have to read() all of .text if the actual execution path
     only takes you to a couple of routines.
   * an optimization for regular I/O. To some extent, I've always
     wondered why read always takes its second argument -- a lot of
     times I don't really care where the buffer with the data I need
     ends up in my address space.

That's pretty much it. Everything else, feels like a hack in a dire
need of a better abstraction.

Thanks,
Roman.