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] ?


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

Reply via email to