All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-core] [REQUEST] eliminate the rthal_critical_enter/exit() from rthal_irq_request()
@ 2006-04-12  8:38 Dmitry Adamushko
  2006-04-15 21:44 ` [Xenomai-core] " Philippe Gerum
  0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Adamushko @ 2006-04-12  8:38 UTC (permalink / raw)
  To: xenomai, Philippe Gerum

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


^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-04-27 12:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-12  8:38 [Xenomai-core] [REQUEST] eliminate the rthal_critical_enter/exit() from rthal_irq_request() Dmitry Adamushko
2006-04-15 21:44 ` [Xenomai-core] " Philippe Gerum
2006-04-22  9:54   ` Dmitry Adamushko
2006-04-24  8:19     ` Philippe Gerum
2006-04-24  9:28       ` Dmitry Adamushko
2006-04-27  8:16         ` Dmitry Adamushko
2006-04-27 12:21           ` Philippe Gerum

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.