Dataspaces and sub-region mapping

[Norman Feske]

Hi Daniel,

> I have a server which own as Ram_dataspace and dishes it out to client's
> by using sub-rm attachments.
> 
> If I pass back to the client the Dataspace_capability for the sub-rm, am
> I correct in saying that the client cannot get to the physical address
> of the mapped region since this is a Dataspace not a Ram_dataspace?
> This this case I'd need to pass it back explicitly as an extra param.

that's correct. A managed dataspace is assembled out of (potentially)
multiply other dataspaces, each located at a different physical address
range. As there is no single physical contiguous address range for the
whole managed dataspace, we cannot return a meaningful value as
'phys_addr'. Hence, you'd need to add an extra interface for querying
the physical address of (a portion of) the managed dataspace.

Given your description, I guess, you are using a managed dataspace to
emulate RAM dataspace, which can be transparently revoked, or migrated
to another physical location?

> Also, can you clarify the difference between Dataspace and Ram_dataspace
> and how you can convert (if at all) between the two?

There is no functional difference. The dataspace type merely denotes the
interface from where the dataspace originated from. E.g., a
'Rom_dataspace' originates from 'Rom_session', an 'Io_mem_dataspace'
originates from 'Io_mem_session', etc. Because all those types are
derived from the 'Dataspace' base type, you can use a 'static_cap_cast'
to convert the types. E.g.,

  Ram_dataspace ram_ds_cap;
  Dataspace     ds_cap;
  ...
  ds_cap = static_cap_cast<Dataspace>(ram_ds_cap);

The capability-type-casting rules are analogous to using 'static_cast'
for C++ types. The cast function templates are located at:

  base/include/base/capability.h

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth