Background first: I have a bounded, and rather small amount of handles reserved per process. So anything that depends on a handle pointing to it, is also bounded, which is good, because it keeps the amount of resources a process can consume bounded. I'm not really trying to totally avoid overcommitting resources; rather I want to limit the damage a single malicious (or buggy) process can do.
I also like to avoid servers needing handle-pre-client, because while I'm happy to limit the number of services a single process can use (at the same time), there's little point running several instances of a server just because the server wouldn't be able to serve more clients, because it's out handles. That's just stupid, as it just wastes resources.
The above might help people understand what follows:
Any process can create a memory objects. Who creates the object is not really important. What is important is that the "client" has a handle to it, and it can use that handle to map the object into it's address space. If it loses the handle, it loses the mapping, and the object gets destroyed.
Since the number of objects a process can have is bounded by the number of handles it can have (like anything else), you can only map a limited number of these objects into any single process. This is not really a problem (it's by design anyway).
Now, I also want virtual memory providers to be able to give out ANY number of objects, but they must be able to control them (basicly: revoke, check if modified, check if accessed, make read-only, possible optimizations: revoke if not modified, revoke if not accessed) in order to implement useful services with them.
So the solution I've come up: have the memory objects in kernel, and have client have handle (one that allows mapping but not control) but have any single memory object have a single memory provider, and have them linked to the memory provider such, that the memory provider can enumerate the objects pointing to it, without needing a handle for each.
This is a bit unpure, because it means I'm going to need additional system calls beyond messaging; it's no good using messaging, because those can be proxied, and allowing memory object control be proxied is ... hmmh ... I have to consider but it feels like bit too much trouble, mainly for security. ???
Anyway, the memory provider can map pages that are mapped into it's own address space, into those memory objects, normally when it gets messages from page faults, avoiding enumeration there, because it also gets a direct (control) handle with a page fault message.
So a provider that doesn't bother with revocations needs to do nil (well give the pages). For revocation, it can enumerate and revoke (something like, get handle to first, then next, then next, and any handle allows controlling that mapping... or something).
But the really cool thing is that if a memory providers own memory is revoked, then we have the objects linked to it already in kernel, so it's trivial to go through them and revoke any futher (physical page, not object) mappings automatically.
So, basicly, I can have something somewhat similar to L4 hierarchical mappings, but bounded to the number of handles in the system, which is bounded to the number of processes in the system, which is bounded by the amount of memory in the system (as a fraction of total pages), which is good, because it means I can also do some kind of accounting on memory usage.
....
Hope this makes some sense to someone. Please ask if something doesn't seem to make sense, because I'd rather catch any stupidities now, and not later. Explaining design also helps understand it better (which is why I'm trying in the first place).
....
Oh, and please don't say "that'll be very bad for performance" because from the performance point of view, I think I know what trade offs I'm making. It'll not be nearly as bad as it initially looks like..
