Hi, the following question/suggestion :
it could be good to eliminate the use of rthal_critical_enter/exit() from rthal_irq_request() if it's not strictly necessary. the proposal : int rthal_irq_request (unsigned irq, rthal_irq_handler_t handler, rthal_irq_ackfn_t ackfn, void *cookie) { - unsigned long flags; int err = 0; if (handler == NULL || irq >= IPIPE_NR_IRQS) return -EINVAL; - flags = rthal_critical_enter(NULL); - - if (rthal_irq_handler(&rthal_domain, irq) != NULL) - { - err = -EBUSY; - goto unlock_and_exit; - } - err = rthal_virtualize_irq(&rthal_domain, irq, handler, cookie, ackfn, - IPIPE_DYNAMIC_MASK); + IPIPE_DYNAMIC_MASK|IPIPE_EXCLUSIVE_MASK); - unlock_and_exit: - - rthal_critical_exit(flags); - return err; } IPIPE_EXCLUSIVE_MASK causes a -EBUZY error to be returned by ipipe_virtualize_irq() when handler != NULL and the current ipd->irqs[irq].handler != NULL. (IPIPE_EXCLUSIVE_MASK is actually not used at the moment anywere, though ipipe_catch_event() is mentioned in comments). Another variant : ipipe_virtualize_irq() should always return -EBUZY when handler != NULL and the current ipd->irqs[irq].handler != NULL, not taking into account the IPIPE_EXCLUSIVE_FLAG. should work if : o all the ipipe_domain structs are "zeroed" upon initialization (ok, in case of static or global); o ipipe_virtualize_irq(..., handler=NULL,...) is always called between possible consecutive ipipe_virtualize_irq(..., handler!=NULL, ...) calls. But, yep, this way we enforce a policy for ipipe_virtualize_irq() so that the use of IPIPE_EXCLUSIVE_FLAG is likely better. esp. for the nucleus where every rthal_irq_request() has a conforming rthal_irq_release() call. Why do I want to eliminate it? o any function that make use of critical_enter/exit() must not be called when a lock (e.g. "nklock") is held. ok, xnintr_attach() was always the case and it's used properly e.g. in native::rt_intr_create(). but xnintr_detach() is now the case too (heh.. I have overlooked it in the first instance) because xnintr_shirq_detach() is synchronized wrt xnintr_shirq_attach() using critical_enter/exit(). This is only because xnintr_shirq_attach() make use of rthal_irq_request() ---> rthal_critical_enter/exit(), hence the nklock can't be used in xnintr_shirq_*. Yep, another approach is to enforce the policy that both xnintr_attach() and xnintr_detach() must never be called when the nklock is held (say, rt_intr_delete() should be rewritten)... but I guess, the better solution is to eliminate the critical_enter/exit() from rthal_irq_request(). o there is no need to use cirtical_enter/exit() in xnintr_shirq_* anymore, the nklock can be used instead. this would solve one synch. problem in xnintr_* code, though there is yet another and more complex one I'm banging my head on now :o) -- Best regards, Dmitry Adamushko _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core