All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomas Kalibera <kalibera@domain.hid>
To: xenomai@xenomai.org
Subject: [Xenomai-help] Interrupt handling questions
Date: Sat, 19 Apr 2008 14:17:53 -0400	[thread overview]
Message-ID: <480A3751.2020609@domain.hid> (raw)


Hi,

I've read the Adeos whitepaper ("Live with Adeos"), API docs, and looked 
at the sources, but I still have some interrupt handling questions.

First, the optimistic interrupt protection. Live with Adeos says that 
Adeos uses optimistic interrupt protection. In optimistic interrupt 
protection, the handled interrupt is not masked at entry to interrupt 
handler, but only on the second entry, if it really recurs. The 
recurring interrupt is handled after the first one is handled. The 
"optimism" is in hoping that the interrupt in fact would not recur and 
is motivated by saving time on masking/unmasking on the fast path.

However, the Xenomai API says (in kernel space rt_intr_create) that the 
handler is already called with the interrupt masked at hardware level. 
Unless the handler returns with RT_INTR_NOENABLE, the interrupt would be 
umasked at hardware level when the handler returns. Where is then the 
optimistic interrupt protection used ? And, does this really happen for 
all I/O interrupts (in particular, not only level triggered, but also 
edge triggered) ? And, are the interrupts also acknowledged by Xenomai ?

Live with Adeos says that a domain is stalled before entering an 
interrupt handler in the domain, which means that further interrupts are 
not delivered to the domain. The domain is automatically unstalled when 
the handler finishes. Does the stalling prevent all interrupts from 
being delivered to the domain ? Or does it only prevent the interrupt(s) 
that are being served by handlers presently running in the domain ?

Life with Adeos says that disabling an interrupt (rthal_irq_disable) 
disables the interrupt at hardware level and also locks out delivery of 
the interrupt to the current domain, preventing logged interrupts to be 
re-played. Similarly, it says that enabling an interrupt enables the 
interrupt at hardware level and unlocks its delivery to the current 
domain. Is the "locking delivery to current domain" the same as stalling 
the domain which happens when the handler is started ?

Life with Adeos also suggests that, because a domain is stalled when 
handler is invoked and interrupts are logged, handlers do not need to 
disable the handled interrupt at hardware level explicitly. But, aren't 
the handlers already called with the interrupt disabled at hardware 
level ? So how could the logging take place ?

Which is even more puzzling to me, the text suggests that not only the 
handled interrupt should not be disabled explicitly, but we should 
enable it to allow it being received by Xenomai and logged for the 
domain. The example uses rthal_intr_enable, which however would also 
unstall the domain, right ? So, wouldn't it  lead to logging of the 
interrupts, but to reentrant invocation of the handler ?

Thanks!

Tomas






             reply	other threads:[~2008-04-19 18:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-19 18:17 Tomas Kalibera [this message]
2008-04-20  9:07 ` [Xenomai-help] Interrupt handling questions Philippe Gerum
2008-04-23  4:42   ` Tomas Kalibera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=480A3751.2020609@domain.hid \
    --to=kalibera@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.