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
