Hi Norman, As always, thanks for your guidance and quick feedback. For our current purpose the overhead of using RM session is OK since the application itself manages large chunks of memory. The alias API would be really nice though.
Best, Daniel
On Tue, 2013-04-30 at 18:18 +0200, Norman Feske wrote:
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