Sawmill's dataspaces and the Hurd's physmem

[Bernhard Pöss]

Neal H. Walfield wrote:

>I understand this to mean that a client depends on a DM to:
>
> - provide mappings to data
> - provide resources backing the data
>
>*snip*
>                    [ Physmem DM ]
>                          |
>                          v
>                      [ FS DM ]
>                          |
>                          v
>                      [ client ]
>
>  
>
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.

In fact my opinion is that the Dataspaces paper is very vague in some 
points especially concerning
protocols for pagefault,... and implementation details.

See 
http://i30www.ira.uka.de/teaching/coursedocuments/117/week10-dataspaces.pdf 
for more details on
implementing dataspaces.

>*snip*
>                      [ physmem ]
>                       /       \
>                     |_         _|
>                [ client ]     [ FS ]
>  
>
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.


Regards,
Bernhard