From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 30 Jul 2008 17:29:05 +0200 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20080730152904.GA17909@nibiru.local> References: <20080717142135.539A31E8C1C@holo.morphisms.net> <20080729085214.GA3072@nibiru.local> <20080729162639.GA31092@satori.no-ip.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080729162639.GA31092@satori.no-ip.org> User-Agent: Mutt/1.4.1i Subject: Re: [9fans] mmap Topicbox-Message-UUID: f5b45164-ead3-11e9-9d60-3106f5b1d025 * Venkatesh Srinivas 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: info@metux.de skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------