At Mon, 05 Sep 2005 21:59:30 +0200, Bernhard Pöss wrote:
The design for a Dataspaces environment would be as follows: Simplified you've got:
- Dataspace Manager providing open / close / map / grant
- Region Mapper providing attach / detach and pf handling
- client
client and region mapper are in the same address space(AS). Think of a region a continous area of virtual memory in the clients AS that makes a part of a dataspace available to the client.
[ dataspace manager ] | request page for region | [ region mapper | client ] | | |--<--- PF -<-|
A page fault scenario would be as follows:
- The client triggers a page fault
- The region mapper (pager of client) receives PF
- The region mapper requests the page from the dataspace manager
(possibly with a timeout) 4.A The dataspace manager maps/grants the page to the region mapper and thus to the client (same AS) 4.B The dataspace manager denies to map the page / timeout fires 5. The region mapper is free to act upon the behaviour of the dataspace manager
An open - attach scenario would be:
- client sends open call to DS manager, receives dataspaceid (DSID)
- client attaches to the region mapper with the DSID
- Now the region mapper is capable of resolving PF in the region the DS
is mapped
I hope I've pointed out where your interpretation was missdirected.
Thanks for the explanation but I don't understand what in your text you think is inconsistent with my understanding of data spaces. The issue that I have noted is that after a DM maps an fpage to a client, the DM can unmap it at any time. My claim is that the result is that the client of the DM must trust the DM to always provide a mapping or it must make a physical copy of the fpage.
Besides the general discussion about dataspaces here, isn't your approach very centralized and thus a possible bottleneck for the system ? One of the ideas behind dataspaces was in fact to decentralize memory management by e.g. stacking dataspace managers.
I think it is fair to say that the root of the DS hierarchy is also centralized. I've designed the physmem interfaces to provide what I view as the minimum required mechanisms to maximize sharing and flexibility, minimize trust and permit accountability. As I understand the DS model, I think my approach is better for each of these four points. I may, of course, be overlooking something. This email thread is specifically about the security issue, however, I'm interested in discussing if my approach is really minimal and what alternative approaches there are.
Thanks, Neal