Splitting Dataspaces

[Norman Feske]

Hi Daniel,

> Sorry, this should be "give some part to process P2".  Anyhow, is the
> answer to use Rm_session and its dataspace method?

this would indeed work. But this solution comes at the cost of
maintaining one RM session per dataspace. Depending on your use case,
this might be quite expensive. E.g., if you want to virtualize core's
RAM service per by allocating a large chunk of RAM at core and then
handing out many small parts of this backing-store chunk as individual
dataspaces, you will need to keep in mind that for each RM session, an
RM client donates 64KiB of quota per RM session (see
'base/include/rm_session/connection.h') to core.

I think a way to create aliases for existing RAM dataspaces would be a
handy feature. I am thinking in the lines of adding an interface like
the following:

Dataspace_capability Ram_session::alias(Dataspace_capability dataspace,
                                        bool                 writable,
                                        off_t                offset,
                                        size_t               size);

This function would create a new dataspace capability that refers to a
subrange of the specified 'dataspace'. In addition to accommodate your
use case, the 'writable' argument would further allow for downgrading
the write-permission of a RAM dataspace to read-only. So RAM dataspaces
can effectively turned into ROM dataspaces, which is a feature sorely
missing in the current API.

That said, there are some obstacles that hindered me to implement this
feature yet. First, it will never work perfectly on base-linux, where
each dataspace is represented by a file descriptor. As far as I know,
there is no way to create an FD for a part of a file. Consequently, the
aliased dataspace will need to refer to the original dataspace FD. So a
process who obtains an alias will be able to access the original one.
(i.e., reverting the downgrade of permissions)

Second, this feature will add complexity to the RAM service in core.
Right now, dataspaces always refer to disjoint physical RAM areas, which
will no longer be the case. One particular question is how to handle the
lifetime of dataspaces and aliased dataspaces. Are aliases destroyed
automatically if the original dataspace is freed? Or does each alias
represent a first-class RAM dataspace? The latter solution would be nice
interface-wise but quite complicated to implement. When freeing one of
them, we would need to take care to release only those parts of physical
RAM that are not referred to by any other alias. I have to think about
that more thoroughly.

That said, those problems can definitely be solved and a feature like
that is important to have.

In any case, the RM session mechanism you mentioned can emulate the
aliasing feature right now (its just expensive). So I recommend using
this mechanism as a stop-gap solution.

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