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 > > [email protected] > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
