On Sat, Nov 09, 2002 at 08:01:55PM +0100, Ulrich Weigand was heard to remark: > Linas Vepstas wrote: > > > But in my storage-key world, I can imagine spearating the strcture > > from the data, and putting the structure in read-only memory, where the > > app can see it but not corrupt it, and putting the data in a read-write > > key, where the app can do whatever it wants. > > And *once you have cleanly separated the two* (which is the > diffcult part), why can't you just put them into two separate > files, one of which is mmapped read-only?
because the library still needs to have read-write access to the data. Think about it. > > In this kind of app, if you had to hide the data behind a socket, > > I claim you would get performance roughly comparable to ordinary > > file-io, and nowhere near the speed of memory-mapped io. > > In Linux, memory-mapped io is usually somewhat slower than > file-io. (Both access the same page cache, but mmap in > addition has to maintain all those page tables ...) There Depends on the access pattern. Doing pointer math is a lot faster than calling read()/write(), esp. when the page in question is already mapped, and one is doing multiple writes. It can be hard to modify a library/app to consolidate memory access so that fewer write()'s can be used. > Just use mmap, and use file access rights to protect the data. How can a library get read-write access to a file, while preventing the app from writing to the same file? > Because the library call has switched the PSW key, that was your > whole point, wasn't it? So if the caller was able to access that > memory, the callee (running with a different PSW key) won't be. OK, on this point, maybe I am indeed quite stupid. It has been years since I last looked at the 390 instruction set. Can't one set a read-only mode for selected PSW keys? > I do not doubt that you might find some problems where the S/390 > storage keys could help. But I'm not convinced that any such > solution will be significantly easier to implement and/or show > significantly higher performance than solutions that could be > implmented using the generic Unix protection mechanisms (separate > processes, mmap, file access rights). OK, I presented a spcific example, from the land of graphics hardware, from the mid 1990's, where these traditional unix solutions completely failed. You can choose not to beleive me, or you can root around in the technical literature from that era (e.g. siggraph proceedings) to discover some of the novel machines that were built. These machines drove a multi-billion dollar industry at the time, and offered significant performance improvements (at least 10x and up from there) over "generic Unix protection mechanisms". > In any case, I have still not quite understood just how the > solution you are proposing is supposed to work. Could you > give an example of a problem you want to solve, and how you > would go about it? OK, take for example, the X11 server. Rip out the socket communications part, and let the xlib calls call directly those routines that the X11 server would call, after it decodes a bit of protocol it read from a socket. > (I.e. which memory areas get what storage > key, what's in them, what pieces of code run under which > PSW key and/or mask, and at what places the keys are switched?) The psw key would switch at the xlib boundary. The memory that is in the x-server would run under the x-server's key, while the client would run under a different key. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
