Hi Jan,

Thank you for your answer! But I still have some things I do not really understand.

In Life with Adeos I read :

The stage of the pipeline occupied by any given domain can be stalled, which means that
the next incoming interrupt will not be delivered to the domain's handler, and will be
prevented from flowing down to the lowest priority domain(s) in the same move. While a
stage is stalled, pending interrupts accumulate in the domain's interrupt log, and
eventually get played when the stage is unstalled, by an internal operation called
synchronization.

and further on :

When a domain has finished processing all the pending interrupts it has received, it then
calls a special Adeos service which yields the CPU to the next domain down the pipeline,
so the latter can process in turn the pending events it has been notified of, and this cycle
continues down to the lowest priority domain of the pipeline.

So from reading this I would suspect that multiple IRQs could be buffered (= interrupt log) between Xenomai and Linux so that Xenomai can finish it realtime jobs. Only when xenomai is done with its jobs the IRQs from the buffer are passed to Linux
But from your answer I suspect that it only holds for different IRQs, and when an IRQ X is on the pipeline not another newer IRQ X can over the pipeline until the first one is dealed with.
Thus when the 'end-of-IRQ' signal is given.
Who however gives this 'end-of-IRQ' signal? linux or the pipeline?
What exactly is this 'end-of-IRQ' signal?
Because interrupt are virtualized in the pipeline I would suspect this is something used in the pipeline?

IRQ sharing between deterministic and non-deterministic code (here:
Xenomai and vanilla Linux) will never work, that's an inherent design
issue, nothing Xenomai or ipipe-specific.

with inherent design, I would guess you mean the intel hardware design I suppose?
but than I would suspect that the 'end-of-IRQ' signal is something in the hardware

please help me out this world of confusion :)

cheers
Harco

Jan