[Xenomai-core] How to hook genirq best

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

Hi all,

in an earlier thread on I-pipe for 2.6.19-ppc from Xenomai-core,
Wolfgang remarked:
>>> Unfortunately, "generic" applies only to the Linux part. I
>>> realized, that the new IPIPE support for the genirqs requires
>>> even more arch-specific modifications than the old interface :-(
>>> on PowerPC.
>> 
>> How comes? I haven't found time to analyse this for the latest x86 
>> patch, but there it should be "more generic" than before. Do you
>> think this is a genirq issue or an I-pipe problem?
> 
> Well, it's nothing serious and we should discuss this issue in a 
> separated thread. I just wanted to have a closer look to the new port
>  before asking. At a first glance I saw that the irq_chip structure
> has two new elements, ipipe_ack and ipipe_eoi. This requires patching
> of every PIC interface. There are a few for x86 but plenty for
> PowerPC. Philippe, is this really necessary? I would prefer the old
> style using "#ifndef CONFIG_IPIPE" around the "chip->ack" in common
> code.

I had a look at the related part in 2.6.19-i386-1.6-01 meanwhile, and
there seems to be a concise pattern for the irq_chip changes:

.ipipe_ack = (.mask_ack) ? .mask_ack : .ack;
.ipipe_eoi = .eoi;

I agree with Wolfgang, these changes indeed require a lot of patching
already on x86 because often two versions of the irq_chip definition
have to be provided (and there is the risk to miss one as it currently
seems to be the case in visws_apic.c).

I must confess that I do not see the advantage of the approach to patch
the irq_chip definitions directly. Rather, one of the following ways
should scale better over a large number of irq_chips:

A) Perform patching during runtime when I-pipe is taking over the IRQs.
Should be a trivial loop over all IRQ descriptors. Either overwrite the
existing irq_chips (i.e. like sketched above) or provide new pseudo
irq_chip structures to Linux.

B) Patch the users of chip->ack/eoi/mask_ack or whatever. Given that
this should basically be confined to kernel/irq/chip.c, it looks
manageable too and would also avoid any useless runtime checks for NULL
handlers or even calling void functions.


Another topic is how to deal with pending IRQs. I haven't looked through
all cases yet, but already the fasteoi one seems to differ in I-pipe
when comparing to a similar situation in -rt: threaded IRQs. -rt ends
(eoi) and masks such IRQs that are about to be deferred to thread
context, I-pipe only ends them. Generally, the question remains for me
if at least IRQs arriving to a stalled I-pipe domain should always be
masked on ack and unmask when being replayed.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]