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: > 1. The client triggers a page fault > 2. The region mapper (pager of client) receives PF > 3. 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: > 1. client sends open call to DS manager, receives dataspaceid (DSID) > 2. client attaches to the region mapper with the DSID > 3. 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
