proxy memory objects

Hi,

I just talked to Thomas about proxy memory objects.  He mentioned two ways
to implement them.  To quote him:

"The traditional version is trivial.  You implement a new kind of
 kernel object, one which you can't actually send any messages to ever.
 vm_map checks to see if the incoming object is one of these.  The
 proxy objects are associated in the kernel with a real memory object
 and a permissions description.  If it is, then you validate the
 request, and install a normal mapping using the underlying object.
 Range restrictions are trivially implemented.  Access restrictions are
 implemented by setting the initial value of the maximum protection on
 the region; vm_protect can only reduce access to that, never increase
 it.

 The better version is trickier.  The proxy object is now a full-blown
 memory object; the kernel functions as the paging server.  When this
 paging server gets requests, it validates them and then either errors
 back or forwards the request to the real paging server.  So far this
 could be done in user space, but it can result in double paging.  So
 the kernel is also clever.  When the real paging server returns a
 page, you have to set up some kind of special magic to have the page
 attached to both the real object and the proxy object.  This is a fair
 bit of work; I don't think it fits nicely in the current framework."

The second option is much more transparent, sexy, proper, aesthetically
sound, etc.  The first one is actually something I can implement in a day,
and is all I can get myself to do (I can be lazy, too :).  The good thing is
that the interface for both is the same, so we would not need to change any
user code if we would do it properly later.  The good thing about the first
one is that if we consequently use it, we can be sure that normal users
don't meddle at all with our memory objects, so it might be a good idea to
use them for both read and read-write access just to be on the safe side.

What I am willing to negotiate is the actual interface to add.  It can be
anything from

routine memory_object_create_proxy (
	memobj: memory_object_t;
	new_max_protection: vm_prot_t;
	out memobj_proxy: memory_object_t);

to

routine memory_object_create_proxy (
	memobj: memory_object_t;
	new_max_protection: vm_prot_t;
	vm_address_t: range_lower_limit;
	vm_address_t: range_upper_limit;
	other_memobj: mach_port_array_t;
	out memobj_proxy: memory_object_t);

In other words, we can anticipate as many extra features as you want, as
long as I don't have to implement them.  Personally, I can sleep happily
with just the first version above.  But I remember that Roland had some
ideas how to exploit fake memory objects further, so he might want something
more fancy.

You know that we absolutely must have them if we ever want to go outside and
say without feeling guilty that people should try out the Hurd.  That's why
I am willing to push the simpler solution even if it is not the best one.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/