bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Patch 0/2] Proxy memory objects revisited


From: olafBuddenhagen
Subject: [Patch 0/2] Proxy memory objects revisited
Date: Mon, 18 May 2009 07:44:54 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

The graphics server needs to pass the framebuffer memory to clients via
io_map(). The framebuffer is an mmio region, i.e. a region of the
physical address space that needs to be mapped directly. The iopl device
provides this functionality; however, the memory object obtained from it
is not suitable for passing to clients: Although Mach's device_map()
does have "offset", "size" and "prot" arguments, none of these are
actually implemented -- it always maps the whole address space. This is
essentially unfixable, as Mach devices do not keep any per-open state.

So the memory object needs to be proxied. I was in horror of having to
implement a full pager -- but then I remembered there was some talk
about proxy memory objects in the past. So I looked it up, and indeed
it's just what I need. Only that Marcus' original patch doesn't
implement anything but prot, while I need offset and length as well.
Thus I created two simple patches adding these.

The "offset" patch is rather trivial. 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?

The patches go on top of Marcus' original patch BTW, but I can provide a
wrap-up patch as well of course if that's more helpful.

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]