Splitting Dataspaces
Daniel Waddington
waddy16925 at ...9...
Tue Apr 30 23:02:13 CEST 2013
OK, fixed it. The Rm_connection object was being destroyed and as a
result invalidating the cap before it got marshaled.
Daniel
On Tue, 2013-04-30 at 12:34 -0700, Daniel Waddington wrote:
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
More information about the users
mailing list