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.
