Hi David,
On 11/15/2017 08:56 AM, David Werner wrote:
Hi Stefan,
thank you for your response. It helped me a lot!
I extended the constructor of of Genode::Signal_source_rpc_object without any problems.
When i try to access the Cpu_thread_component pointer t within the lambda method which is handed to "entrypoint.apply(...)" i get the following compiler issues:
   COMPILE cpu_session_component.o In file included from /home/david/genode-kia4sm/repos/base/src/core/include/signal_source_component.h:17:0,
                from /home/david/genode-kia4sm/repos/base/src/core/include/signal_broker.h:17,                 from /home/david/genode-kia4sm/repos/base/src/core/include/pd_session_component.h:30,
                from /home/david/genode-kia4sm/repos/base/src/core/include/cpu_thread_component.h:26,
                from /home/david/genode-kia4sm/repos/base/src/core/include/cpu_session_component.h:27,
                from /home/david/genode-kia4sm/repos/base/src/core/cpu_session_component.cc:21: /home/david/genode-kia4sm/repos/base-focnados/src/include/signal_source/rpc_object.h: In lambda function: /home/david/genode-kia4sm/repos/base-focnados/src/include/signal_source/rpc_object.h:54:14: error: invalid use of incomplete type âclass Genode::Cpu_thread_componentâ      return t->platform_thread().thread().local.data()->kcap();
this is the most interesting information here. The compiler tells you it does not know enough about the class Genode::Cpu_thread_component at this point. See a some lines further down.
             ^ In file included from /home/david/genode-kia4sm/repos/base/src/core/include/cpu_thread_component.h:25:0,
                from /home/david/genode-kia4sm/repos/base/src/core/include/cpu_session_component.h:27,
                from /home/david/genode-kia4sm/repos/base/src/core/cpu_session_component.cc:21: /home/david/genode-kia4sm/repos/base/src/core/include/cpu_thread_allocator.h:26:8: error: forward declaration of âclass Genode::Cpu_thread_componentâ  class Cpu_thread_component;
As you can see here, the compiler has only information via this forward declaration of the class Cpu_thread_component. The full declaration is missing, because the header containing Cpu_thread_component could not be included here - for reasons.
A simple solution would be to remove the implementation of the constructor, and just declare it within the header file. Move the implementation of the constructor to some appropriated compilation unit (*.cc) within core, and include the header containing Cpu_thread_component within it.
Regards Stefan
       ^ /home/david/genode-kia4sm/repos/base/mk/generic.mk:56: die Regel für Ziel âcpu_session_component.oâ scheiterte
I have no idea what this is trying to tell me. Do you have an idea what the problem here is?
Kind regards, David
Am 02.11.2017 um 14:03 schrieb Stefan Kalkowski:
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
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