This looks like a fine addition. One could imagine more complex schemes, which enable remapping (think scatter/gather type mechanisms), however, I don't think that this is generally useful. Further such additional functionality would significantly increase the complexity whereas your proposal is a very simple addition, which adds very useful functionality.
At Mon, 18 May 2009 07:44:54 +0200, <olafbuddenha...@gmx.net> wrote: > I'm not entirely sure about the > "size" one however: It works by mapping only as many pages as the proxy > object allows, even if the client requested more. This does serve the > purpose for me (prevent the client from getting access to regions it > isn't allowed to access); and it is in a way equivalent to what the > original patch does about prot: It provides a map trimmed to what the > client is actually allowed. I wonder though whether creating a mapping > with less pages than the client expected isn't problematic. What do you > think? A proxy object narrows a view (and thus access) of the object it proxies. If the underlying object consists of 100 pages and the proxy object is set up to allow the user access to just 10, then a client should only be able to access those 10. Moreover, the client should not be able to distinguish whether a proxy object is a normal memory object or proxied (i.e., the proxying should be transparent). Given this, if a client tries to map more pages than are accessible by a proxy object, it should be equivalent to what happens when a client tries to map more pages than are accessible by a memory object. I'd guess that the kernel would return KERN_INVALID_ARGUMENT but this needs to be confirmed. Also, I don't think that there is any need to split the offset and length patches up. Really, if one wants one addition, then the other is likely also needed. Neal
