Splitting Dataspaces

[Daniel Waddington]

One last issue in doing this...  I create the sub_rm and test it in the
creating process, this works fine.  When I try to send out the
Dataspace_capability (as either ref or ptr) for the sub_rm through RPC
to another process, then I get an invalid capability on the recv side
(as determined by .valid()). 

Is there something I'm missing here?
Daniel

On Tue, 2013-04-30 at 10:13 -0700, Daniel Waddington wrote:
> 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
> > 
> 
> 
> 
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main