Hi David
On 11/02/2017 10:35 AM, David Werner wrote:
Hi,
let me rephrase my question. Is "Thread::myself()->native_thread().kcap" returning the kcap of another capability than "Thread::myself->cap().data()->kcap()" ? As far as i understand yes. The former returns the kcap of the gate capability while the latter returns the capability of the thread object capability.
If that is true, is there a possibility to access the gate capability from withtin the "Signal_source_rpc_object" [/repos/base-foc/src/include/signal_source/rpc_object.h] ?
sorry for my late response!
In fact, Thread::myself->cap() delivers the capability to the thread object representation in core, not to mix up with the kernel-capability that refers the actual thread! Therefore, I advised to send this capability to core, and retrieve the "real" thread's capability out of the Cpu session's object that belongs to the thread. You can use the core's entrypoint, which is the same for Signal, Irq, Cpu, etc. to retrieve the right Cpu_thread_component from the capability delivered by the signal source client. Similar to this snippet:
entrypoint.apply(delivered_thread_cap, [&] (Cpu_thread_component *t) { if (t) ... // attach t->platform_thread().thread().local };
You can store the entrypoint within the Genode::Signal_source_rpc_object by extending its constructor. Cpu_thread_component contains the Platform_thread object of the thread including its "real" kernel capability.
A shortcut might be to propagate the gate capability to core instead, simply by using native_thread(), which you already mentioned. In that case, you can simply attach the received capability to the irq object. But this is just a proof-of-concept implementation and inherently insecure, as it opens up the possibility to attach signal sources to arbitrary threads including threads of other protection domains.
Regards Stefan
Kind Regards,
David
Am 24.10.2017 um 02:11 schrieb David Werner:
Hi Stefan,
i modified the request semaphore call and changed the constructor of the Signal_source_client as follows:
[/repos/base-foc/src/lib/base/signal_source_client.cc] :
Signal_source_client::Signal_source_client(Capability<Signal_source> cap) : Rpc_client<Foc_signal_source>(static_cap_cast<Foc_signal_source>(cap)) { /* request mapping of semaphore capability selector */ _sem = call<Rpc_request_semaphore>(Thread::myself()->cap()); }
[/repos/base-foc/src/include/signal_source/rpc_object.h] :
Native_capability _request_semaphore(Thread_capability tcap) {
Fiasco::l4_irq_detach(_blocking_semaphore.data()->kcap());
Fiasco::l4_msgtag_t tag = Fiasco::l4_irq_attach(_blocking_semaphore.data()->kcap(), 0, tcap.data()->cap()); if (l4_error(tag)) Genode::raw("l4_irq_attach failed with ", l4_error(tag));
return _blocking_semaphore;
}
Unfortunately i run into problems if a component uses a timer. As soon as timer.sleep is called the component waits forever.
After taking a look at some code (especially Platform_thread) I think the problem might be that i now use the kcap of the thread capability for the l4_irq_attach call instead of the kcap of the corresponding gate capability.
Is that right or might there be another reason for my timer problem?
Kind Regards,
David
Am 24.07.2017 um 14:18 schrieb Stefan Kalkowski:
On 07/05/2017 02:00 PM, David Werner wrote:
Hi,
it seems to work if i use <capability>.data()->kcap(). Is that correct?
Yes.
Regards Stefan
Kind Regards, David
Am 05.07.2017 um 13:46 schrieb David Werner:
Hi Stefan,
Am 29.06.2017 um 18:18 schrieb Stefan Kalkowski:
What I meant with:
"... the signal handler thread transfers its identity to core via request_semaphore..."
was that you add an additional argument to the request_semaphore call, which is the CPU session's thread capability of the calling thread, like this:
Thread::myself()->cap()
Core can therewith retrieve the "real" thread capability, in terms of the kernel's thread capability, and attach that to the IRQ object. I hope I could get my ideas across to you.
Best regards Stefan
Thank you! I modified the request semaphore call according to your suggestion.
My only problem is that i don't get how to use the transfered thread capability to retrieve the kernel's thread capability. More precisely, i'm not able to figure out how to determine the correct kcap which i have to use in the l4_irq_attach call (which is now on core's side).
Could you give me some more advise on that?
Kind Regards, David
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main