Am I correct in thinking that, if several drivers connect to the same
interrupt, the order in which their ISRs are called is unpredictable?
I have a PCI device for which I am adding an upper filter driver that
needs to participate in the interrupt handling. What I would like to do
is have the filter get first shot, then if it doesn’t like the
interrupt, let the main driver do its processing.
The order in which the two drivers call WdfInterruptCreate (which, I
assume, calls IoConnectInterrupt) is deterministic, but I don’t know
whether that’s enough.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
There are no order guarantees. Both drivers are connecting isrs to the same physical interrupt?
d
tiny phone keyboard + fat thumbs = you do the muth
-----Original Message-----
From: Tim Roberts
Sent: Friday, March 05, 2010 3:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Interrupt Order
Am I correct in thinking that, if several drivers connect to the same
interrupt, the order in which their ISRs are called is unpredictable?
I have a PCI device for which I am adding an upper filter driver that
needs to participate in the interrupt handling. What I would like to do
is have the filter get first shot, then if it doesn’t like the
interrupt, let the main driver do its processing.
The order in which the two drivers call WdfInterruptCreate (which, I
assume, calls IoConnectInterrupt) is deterministic, but I don’t know
whether that’s enough.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Doron Holan wrote:
There are no order guarantees. Both drivers are connecting isrs to the same physical interrupt?
Yes. That means I’ll have to have some kind of registration scheme so
the main driver knows not to touch the filter’s interrupts. Either
that, or a callback. Not quite as pretty as I’d hoped…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> if several drivers connect to the same interrupt,
…then they happen to share interrupt line, and, hence, vector. However, they are still going to have different KINTERRUPT objects - IIRC, there is one-to-one correspondence between KINTERRUPT object and ISR.
I have a PCI device for which I am adding an upper filter driver that needs to participate
in the interrupt handling. What I would like to do is have the filter get first shot, then if it doesn’t like
the interrupt, let the main driver do its processing.
Once interrupt resource (and, hence, KINTERRUPT object ) is the same for all devices in the same stack, I believe you will fail if you make both FDO and filter call IoConnectInterrupt() with the same KINTERRUPT parameter, in the first place. Therefore, I think your only option is to go the say i8042prt. sys does , i.e. to invoke filter’s interrupt handler as a callback in context of of ISR…
Anton Bassov
Let’s be clear: The order in which they are called is defined by the implementation, and is entirely predictable in my experience. In other words, the order in which ISRs are called isn’t randomized in any way. The order, however, is not architecturally guaranteed… which is what I think Doron was saying.
IIRC, the last time I looked at this (quite a while ago) the ISRs were called in the order in which their drivers registered for the interrupt. The Interrupt Objects were linked at the END of the list when they were created. But, like I said, that’s entirely from memory and an artifact of implementation. A few quick tests would be all that’s necessary to verify this.
If that level of assurance is acceptable for your project, then you’re probably all set. But if you have control of the main driver code, in ANY case things will be much more clear for future maintainers (not to mention much more architecturally sound) by creating a registration scheme. That’ll make it obvious when looking at the main driver’s ISR code that somebody else is playing in the same area.
Peter
OSR
> If that level of assurance is acceptable for your project, then you’re probably all set.
… apart from the fact that he seems to be speaking about using the same KINTERRUPT parameter in multiple calls to IoConnectInterrupt() - he made it clear that drivers that share a vector participate in the same stack as respectively FDO and upper filter. KINTERRUPT object is a logical link between vector and ISR that allows sharing vector by multiple ISRs and ISR servicing multiple vectors. Therefore, there must be one-to-one correspondence between KINTERRUPT and ISR, and his design is going to violate this part…
Anton Bassov
The pkinterrupt* object is an out parameter to ioconnectinterrupt, a driver does specify create or alloc the kinterrupt on its own
d
tiny phone keyboard + fat thumbs = you do the muth
-----Original Message-----
From: xxxxx@hotmail.com
Sent: Saturday, March 06, 2010 12:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Interrupt Order
> If that level of assurance is acceptable for your project, then you’re probably all set.
… apart from the fact that he seems to be speaking about using the same KINTERRUPT parameter in multiple calls to IoConnectInterrupt() - he made it clear that drivers that share a vector participate in the same stack as respectively FDO and upper filter. KINTERRUPT object is a logical link between vector and ISR that allows sharing vector by multiple ISRs and ISR servicing multiple vectors. Therefore, there must be one-to-one correspondence between KINTERRUPT and ISR, and his design is going to violate this part…
Anton Bassov
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> The pkinterrupt* object is an out parameter to ioconnectinterrupt, a driver does specify create
or alloc the kinterrupt on its own
…duh… what I have overlooked is that IoConnectInterrupt() just does not care about DO in itself - I should have looked at documentation before making a post…
Anton Bassov
Architecturally speaking, it’s officially unpredictable. In practice,
drivers chain onto the end of the list as they register.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Am I correct in thinking that, if several drivers connect to the same
> interrupt, the order in which their ISRs are called is unpredictable?
>
> I have a PCI device for which I am adding an upper filter driver that
> needs to participate in the interrupt handling. What I would like to do
> is have the filter get first shot, then if it doesn’t like the
> interrupt, let the main driver do its processing.
>
> The order in which the two drivers call WdfInterruptCreate (which, I
> assume, calls IoConnectInterrupt) is deterministic, but I don’t know
> whether that’s enough.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>