Use the terms ISR and IST (interrupt service thread).
ISR (Interrupt Service Routine) - The function that is InterruptAttach()ed.
IST (Interrupt Service Thread) - The thread that issued InterruptAttachEvent() and receives the subsequent events. I had been using “driver” to cover that.
What time?
I start showing up from 4:00 GMT (17:00 my time) but, if you are sitting down much, drop in and say hi to the mottley bunch anyway.
The Address Space switch is almost unavoidable. You can prepare a “callback”, but the kernel
will HAVE to “copy” that piece of routine into kernel space to be able to execute it. Otherwise,
it still need to do the address space switch just to be able to execute the “callback routine”.
To be able to “copy into” kernel space, you need to program the routine very carefully, (usually
in asm) if you really wish to go that far to handle your super critical interrupt, you might as
well write your own interrupt callout in start up 
Those are details for the kernel library to deal with. The driver would just use the API.
But those details are already dealt with; the API is InterruptAttach, and InterruptAttachEvent 
QNX will always switch the address space, since, as Mario states; the handler would be useless. That is to say, there would be no access to any “driver” data unless the whole driver is inside the kernel address space, and then (whoops), we no longer have a ukernel.
Ah, I forgot a little detail … I’m no kernel guru, but the way I see it is the kernel is omni-present in all address spaces. There is no switching for it to access anything. This is one reason why a process doesn’t have all 32 bits to itself.
I’m not saying sharing is higher performance, just that it exists and should be accommodated.
Sharing guarantees more overhead than not sharing. But by how much?
The only extra that must occur is multiple calls into the chain of callbacks/ISRs for checking/clearing the IRQ sources. Each call that returns a negative is lost time.
While chating with evanh on IRC I realized the potential problem I mentionned about interrupt priority inversion doesn’t exists. I assumed that the kernel would only not issue the EIO hence blocking lower priority IRQ till the IRQ is unmask by the thread. Apparently the EOI is issue by the kernel after dealing with the ISR just after it masks the interrupt.
I have to say though I’m confuse, it’s all becoming a blur… Data overload.
Some clarification is needed:
An ISR is executed inline before the EOI. This has the same effect as a mask, within the ISR, but the kernel is not actually performing a mask operation itself.
The ISR must completely deal with the interrupt right there and then. And that includes clearing it’s source.
However, if there is even one IST then the kernel automatically masks the IRQ and sends the event along to all associated ISTs.
Note quite, when an interrupt is masked, lower priority interrupt are making it to CPU. Until EOI is issued lower interrupt are block by the PIC.
No, ISR can behave just line the kernel ISR that handles IAE. It can mask the interrupt, return an event and let a thread clear the source. It’s up to the programmer.
Ok, yes, the ISR can mask the IRQ. But it won’t because that adds even more overhead. If you are going to palm the job off to an IST then InterruptAttachEvent() is better suited.
In the case of share interrupt, doing an IRQ that check if source of interrupt matches and only returns an event if it does is better the InterruptAttachEvent() because, save on context/thread switching (thread receive an event for nothing). All this is up to programmer!
Masking is not an option in that case. Masking is the reason that sharing is not working at the moment.
That’s why I’m wanting a callback added to InterruptAttachEvent(). The device specific code clears the interrupt source, amongst other things, from within the kernel so the mask never occurs.
In reality, prolly a new attaching function would be available and IAE() would be left as is so it wouldn’t upset the existing non-sharing drivers.
evanh - that is called InterruptAttach().
Now, that’s no incentive to change all the existing drivers over, is it?
But yep, I fully recommend that the network drivers all change over to using InterruptAttach() so they can properly share interrupts.
A standard implementation would have the ISR check for it’s device wanting service. If false then return immediately. If true then disable and clear it’s device’s interrupt generation then send an event on to the IST.
The IST, when completed the servicing, would re-enable the device’s interrupt generation. The PIC’s IRQ would stay unmasked at all times.
You are asking for a new API which sound simple but is a tedious process. The new API you suggest also extra overhead over both InterruptAttach and InterruptAttachEvent, which I don’t feel is desirable. Using InterruptAttach is much cleaner, and if you feel you need an incentive to switch from IAE over to IA because of the extra work, then you are in trouble l-)
The reason for the extra function in the API is to fix the problem with InterruptAttachEvent(). Explain how this would add overhead to InterruptAttach()?
Yes, InterruptAttach() can be used but it has the extra context switch, sometimes two extra switches.
And yes, all drivers that are currently using IAE() would have to be changed but this is true no matter what fix is choosen. The incentive is not for me, it’s for all. Cooperation is the only way.
I am plainly stating that IRQ sharing will never work in a plug’n’play fashion without this sort of change.