[Top][All Lists]

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

Re: Sawmill's dataspaces and the Hurd's physmem

From: Neal H. Walfield
Subject: Re: Sawmill's dataspaces and the Hurd's physmem
Date: Mon, 05 Sep 2005 21:31:36 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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.


reply via email to

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