Restoring child with checkpointed state
Stefan Kalkowski
stefan.kalkowski at ...1...
Wed Nov 15 11:24:27 CET 2017
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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
--
Stefan Kalkowski
Genode Labs
https://github.com/skalk · http://genode.org/
More information about the users
mailing list