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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
