* Venkatesh Srinivas <[EMAIL PROTECTED]> wrote:
... redirecting back to 9fans ;-P
> 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.
Well, the biggest problem, IMHO are the incompatible semantics
between platforms, and some things IMHO aren't needed at all.
What I expect from an clean mmap() is:
* map in a given region of some file into process's address space
* mapping types:
a) readonly
b) readwrite
c) private / copy-on-write
* either let the app or the kernel decide on start address
* optional hints on intended access patterns (eg. if it might
be wise to do read-ahead)
Ah, and there should be a special (size-limited) kernel device
which holds evrything in RAM exclusively (never get swapped out)
for holding critical security information.
> There have even been OSes that let userland apps play with their address
> spaces in far more interesting ways - KeyKOS and EROS come to mind. And
> they were even fast, or something.
hmm, never heared about them. what are they doing at this point ?
>
> 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.
Well, mmap() is a tricky thing since it breaks common filesystem
semantics. So it can only be done, and only makes sense on specific
kind of files/devices which are only acessed block-wise. So the
absolute MUST is that the underlying file supports (at least block-
wise) random access - mmap()'ed streams are completely nonsense.
Convenience is one point (sometimes be a big point), but another
important one is sharing. Without mmap(), an (real) shared library
support most likely will require special kernel support.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
