Restoring child with checkpointed state
David Werner
wernerd at ...389...
Wed Nov 15 08:56:07 CET 2017
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();
^
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;
^
/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
More information about the users
mailing list