[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
proxy memory objects
From: |
Marcus Brinkmann |
Subject: |
proxy memory objects |
Date: |
Tue, 19 Nov 2002 09:46:21 +0100 |
User-agent: |
Mutt/1.4i |
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 address@hidden
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/
- proxy memory objects,
Marcus Brinkmann <=
- Re: proxy memory objects, Marcus Brinkmann, 2002/11/19
- Re: proxy memory objects, Thomas Bushnell, BSG, 2002/11/21
- Re: proxy memory objects, Marcus Brinkmann, 2002/11/21
- Re: proxy memory objects, Thomas Bushnell, BSG, 2002/11/21
- Re: proxy memory objects, Marcus Brinkmann, 2002/11/21
- Re: proxy memory objects, Thomas Bushnell, BSG, 2002/11/21
- Re: proxy memory objects, Marcus Brinkmann, 2002/11/22
- Re: proxy memory objects, Thomas Bushnell, BSG, 2002/11/22
Re: proxy memory objects, Marcus Brinkmann, 2002/11/20