Hi Stefan, OK, I think this clears things up for me - the hazards of Genode hacking! ;)
Thanks for your help as always, Daniel
On 02/19/2013 02:15 AM, Stefan Kalkowski wrote:
Hi Daniel,
On 02/19/2013 01:38 AM, Daniel Waddington wrote:
Hi Stefan,
In my test server side session function, if I use a core-created capability (via alloc_irq) it works. If I try to do similar behavior locally, the capability appears to be valid (i.e., it exists in the jdb object table) but will not martial correctly - .valid() fails at the client side (note my server process has L4_BASE_FACTORY_CAP).
Can you enlighten me? I am clearly doing something wrong.
I see. Well that's the reason I recommended to put such a service into core to you ;-). The point of the matter is: although your self constructed capabilities have valid indices of the capability name space controlled by the kernel, they have invalid IDs (alias "local_name"s). These IDs are Genode specific, and have nothing to do with the kernel API. They are used to find capabilities, a task already owns. Therefore, all capabilities are stored in a task-local AVL tree. The IDs are used as keys in the AVL tree. A capability without a proper ID (ID == 0) is treated as an invalid capability. When you try to marshal a capability into the message buffer, it is checked whether you try to transfer an invalid capability or not. Without that check, the kernel would pollute the debug messages with a lot of warnings about capability transfers that failed. If it is an invalid one, no mapping gets established. That's why no capability is transfered in your case.
I see two opportunities to solve that problem: First, you implement a proper service in core, or use the existing ones (e.g.: Cpu_session::alloc_irq). If you've to implement your own service in core, or extend an existing one, you can use core's allocator for capability IDs: "Platform::cap_id_alloc()".
If for some reason it is impassable for you to do this in core, you might allocate a capability via core's cap_session service for every capability you want to construct by hand. Thereby, you obtain an ID that is not used otherwise. But be careful, this is the path of pain. Because you have to get rid of the capability, allocated via core, in your task-local AVL tree before getting your own capability into it. This should be done via the smart pointer magic only. Don't remove a capability from the tree by hand, when you still have references to it! With other words, you have to get rid of all references to the capability allocated via core, so that its destructor will do the database removal for you. Later, when you want to free your capability again, you'll have to re-construct the capability allocated via core. So that you can go to core's cap_session service, and free it. Otherwise, you'll have a capability leak in core.
Summing up, I hope I could convince you to implement variant number one ;-).
status_t Foo::Session_component::create(Genode::Native_capability& result_cap) { #if WORKS Genode::Foc_cpu_session_client cpu(Genode::env()->cpu_session_cap()); result_cap = cpu.alloc_irq(); #endif
#if DOES_NOT_WORK Cap_index * i = Genode::cap_idx_alloc()->alloc_range(1);
l4_msgtag_t res = l4_factory_create_irq(L4_BASE_FACTORY_CAP, i->kcap()); assert(!l4_error(res));
Genode::Native_capability ncap(i); result_cap = ncap; #endif }
BTW, I'm currently using Native_capabilities to test. But I also do not know how to convert from a Native_capability to a typed capability. ;-) Can you show me?
You can use the following method defined in "base/include/base/capability.h" for it:
template <typename RPC_INTERFACE> Capability<RPC_INTERFACE> reinterpret_cap_cast(Untyped_capability const &untyped_cap);
Best regards Stefan
Daniel
On 02/18/2013 01:15 AM, Stefan Kalkowski wrote:
Hi Daniel,
On 02/14/2013 08:33 PM, Daniel Waddington wrote:
Hi, Can I pass Native_capability types as [out] parameters using "Native_capability *" type - with the cross-process mapping happening? Most of the examples use only use the return value to do [out] capabilities. i.e. GENODE_RPC(Rpc_foo,int,foo,Genode::Native_capability *) doesn't seem to work, but there might be something else afoot.
actually it should work the way you've described it. I've tested it right now by extending the hello example the same way, and the capability was successfully transfered to the calling client as an argument. By the way, why do you use Native_capability instead of Capability? Although both should work, I would use the generic Capability class, especially in an interface.
Best regards Stefan
Daniel
Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main