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

Hi Daniel,

If I create a class which inherits from Dataspace_capability I assume the RPC marshalling/unmarshalling can't deal with it properly?

struct X : Genode::Dataspace_capability { addr_t phys; };

So I can avoid adding extra parameters.

I am afraid that this approach won't work. The delegation of capabilities is handled by the insertion/extraction operator overloads that take a 'Capability<T>' as argument. I am not 100% sure whether or not the operator matches for your type but in any case, it won't work. If the object is regarded as a capability, the capability will be delegated but the 'phys' member won't be transferred. On the other hand, if the object is regarded as a plain data type, the 'phys' value will be transferred, but the capability won't be delegated.

I suggest to add a separate RPC interface function (to the session interface of your service) that takes a 'Dataspace_capability' as argument and returns the physical address as return value).

Maybe there is another solution for the high-level problem you try to solve using the managed dataspace? But given the scarce information I have for now, I am unable to see the big picture, which makes it somehow difficult to assist you.

Cheers Norman