Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

Petr Cervenka wrote:
> I sense, that there could be a problem. the rtdm_nrtsig_handler_t handler have only one argument (rtdm_nrtsig_t *). But I need to get a pointer to the device and/or the event which has happended and needs to be forwarded to tha waiter.

Yes, the nrtsig interface is a bit unhandy in this regard.

Recent restructuring of the Ipipe patch enabled cookie support also for
rtdm_nrtsig_t, but I refrained from extending the signal handler so far
as this would break existing drivers. Well, as the whole rtdm_nrtsig
interface is inline anyway, adding rtdm_nrtsig_init_ex and
rtdm_nrtsig_handler_ex_t might be a cheap option. You could try this
(untested!):

typedef void (*rtdm_nrtsig_handler_ex_t)(rtdm_nrtsig_t nrt_sig,
                                         void *arg);

static inline int rtdm_nrtsig_init_ex(rtdm_nrtsig_t *nrt_sig,
                                      rtdm_nrtsig_handler_ex_t handler,
                                      void *arg)
{
    *nrt_sig = rthal_alloc_virq();

    if (*nrt_sig == 0)
        return -EAGAIN;

    rthal_virtualize_irq(rthal_root_domain, *nrt_sig,
                         (rthal_irq_handler_t)handler, arg, NULL,
                         IPIPE_HANDLE_MASK);
    return 0;
}

Hmm, really simple, I should commit this...

> I hope there is a possibility to search all my devices (usualy one :-)) if the argument belongs to it, and then clear all pending "events" and call wake_up for appropriate wait queues.
> But it's not as simple as I wanted :-(, I hoped that I can avoid the waiting queues etc..
> Anyway thanks for help. I didn't know, that I can't use wake_up from RT interrupt handler.

You may want to wait a bit, I'm currently cooking something as I noticed
that we could also gain some benefit from such "dual-use" rtdm_event.
Our middleware's communication service (RTDM-based) currently requires
RT-receivers, but non-RT is on our which list for quite some time as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]