Hello,
I am a new comer. I have a question:
My user application need to wait for kernel interrupt and than do something.

I think I will pass the request to kernel throught IOCTL call and wait for
return.
My kernel IOCTL function call
KeWaitForSingleObject

When interrupt happen, in ISR DPC, I will call
KeSetEvent

than my IOCTL function will return to user. Is this a good way to implement
this? If not, what is the best way?

Thanks,

Xinshou

Re: How user wait for kernel? by Don

Don
Fri Oct 12 05:15:23 PDT 2007


"Xinshou2" <Xinshou2@discussions.microsoft.com> wrote in message
news:C9A2AC5F-BF53-4D2E-9F10-EC4F69239190@microsoft.com...
> Hello,
> I am a new comer. I have a question:
> My user application need to wait for kernel interrupt and than do
> something.
>
> I think I will pass the request to kernel throught IOCTL call and wait for
> return.
> My kernel IOCTL function call
> KeWaitForSingleObject
>
> When interrupt happen, in ISR DPC, I will call
> KeSetEvent
>
> than my IOCTL function will return to user. Is this a good way to
> implement
> this? If not, what is the best way?
>
The overall concept is the best way, the implementation will not work.
First, have your IOCTL's put into a cancel safe queue (if this is WDF the
framework queue can do this for you, else look at IoCsqXXX functions), then
have the IOCTL code return STATUS_PENDING from the function.

The interrupt service routine needs to queue a DPC and then the DPC can
complete the IOCTL IRP.

The application can then open the device with OVERLAPPED I/O and send down
multiple requests if need be, which will then be processed in order. The
application can wait on an event associated with the IOCTL if it needs to
pend.

Your approach had the following problems:

1. The application thread was blocked in the kernel so could not do
other work, this is not the Windows approach.
2. Multiple threads would all get the same interrupt
3. It is easy to miss interrupts since there is only one request
pending
4. You cannot call KeSetEvent at interrupt level
5. You had no logic to reset the event so after the first interrupt all
future requests return immediately


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply



Re: How user wait for kernel? by Doron

Doron
Fri Oct 12 09:51:58 PDT 2007

since you are just starting out, i would strongly encourage you to use KMDF
to get ths working. IRP queueing and cancelation is not easy in WDM, in
KMDF you get this very easily in addition to all of the pnp/power and other
implementations that you would need to do yo on your own in WDM

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:%23dxtfnMDIHA.5160@TK2MSFTNGP05.phx.gbl...
>
> "Xinshou2" <Xinshou2@discussions.microsoft.com> wrote in message
> news:C9A2AC5F-BF53-4D2E-9F10-EC4F69239190@microsoft.com...
>> Hello,
>> I am a new comer. I have a question:
>> My user application need to wait for kernel interrupt and than do
>> something.
>>
>> I think I will pass the request to kernel throught IOCTL call and wait
>> for
>> return.
>> My kernel IOCTL function call
>> KeWaitForSingleObject
>>
>> When interrupt happen, in ISR DPC, I will call
>> KeSetEvent
>>
>> than my IOCTL function will return to user. Is this a good way to
>> implement
>> this? If not, what is the best way?
>>
> The overall concept is the best way, the implementation will not work.
> First, have your IOCTL's put into a cancel safe queue (if this is WDF the
> framework queue can do this for you, else look at IoCsqXXX functions),
> then have the IOCTL code return STATUS_PENDING from the function.
>
> The interrupt service routine needs to queue a DPC and then the DPC can
> complete the IOCTL IRP.
>
> The application can then open the device with OVERLAPPED I/O and send down
> multiple requests if need be, which will then be processed in order. The
> application can wait on an event associated with the IOCTL if it needs to
> pend.
>
> Your approach had the following problems:
>
> 1. The application thread was blocked in the kernel so could not do
> other work, this is not the Windows approach.
> 2. Multiple threads would all get the same interrupt
> 3. It is easy to miss interrupts since there is only one request
> pending
> 4. You cannot call KeSetEvent at interrupt level
> 5. You had no logic to reset the event so after the first interrupt
> all future requests return immediately
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>


Re: How user wait for kernel? by Xinshou2

Xinshou2
Thu Oct 18 16:07:00 PDT 2007

Don,
Thanks for the answer. It is really help. I still have questions, please see
below:

"Don Burn" wrote:

>
> "Xinshou2" <Xinshou2@discussions.microsoft.com> wrote in message
> news:C9A2AC5F-BF53-4D2E-9F10-EC4F69239190@microsoft.com...
> > Hello,
> > I am a new comer. I have a question:
> > My user application need to wait for kernel interrupt and than do
> > something.
> >
> > I think I will pass the request to kernel throught IOCTL call and wait for
> > return.
> > My kernel IOCTL function call
> > KeWaitForSingleObject
> >
> > When interrupt happen, in ISR DPC, I will call
> > KeSetEvent
> >
> > than my IOCTL function will return to user. Is this a good way to
> > implement
> > this? If not, what is the best way?
> >
> The overall concept is the best way, the implementation will not work.
> First, have your IOCTL's put into a cancel safe queue (if this is WDF the
> framework queue can do this for you, else look at IoCsqXXX functions), then
> have the IOCTL code return STATUS_PENDING from the function.
>
> The interrupt service routine needs to queue a DPC and then the DPC can
> complete the IOCTL IRP.
>
> The application can then open the device with OVERLAPPED I/O and send down
> multiple requests if need be, which will then be processed in order. The
> application can wait on an event associated with the IOCTL if it needs to
> pend.
>
> Your approach had the following problems:
>
> 1. The application thread was blocked in the kernel so could not do
> other work, this is not the Windows approach.

----> I still don't understand, even my IOCTL's put into a cancel safe
queue, application also is blocked, isn't it? because it will not return to
user, until I completed request, isn't it?

> 2. Multiple threads would all get the same interrupt

> 3. It is easy to miss interrupts since there is only one request
> pending
> 4. You cannot call KeSetEvent at interrupt level
-----> Can I call KeSetEvent in EvtInterruptDpc , since it is at
DISPATCH_LEVEL?
from document, KeSetEvent is running at DISPATCH_LEVEL .

> 5. You had no logic to reset the event so after the first interrupt all
> future requests return immediately
>

--------> Other question, if my default queue for IOCTL is
WdfIoQueueDispatchSequential,
can I still do OVERLAPPED I/O in IOCTL?

Thanks,

Xinshou

>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>

Re: How user wait for kernel? by Don

Don
Fri Oct 19 05:40:06 PDT 2007

Comments inline:
"Xinshou2" <Xinshou2@discussions.microsoft.com> wrote in message
news:D76AD4D0-47DD-4AA8-9ECD-B1473CFEF71A@microsoft.com...
> Don,
> Thanks for the answer. It is really help. I still have questions, please
> see
> below:
>
> "Don Burn" wrote:
>
>>
>> "Xinshou2" <Xinshou2@discussions.microsoft.com> wrote in message
>> news:C9A2AC5F-BF53-4D2E-9F10-EC4F69239190@microsoft.com...
>> > Hello,
>> > I am a new comer. I have a question:
>> > My user application need to wait for kernel interrupt and than do
>> > something.
>> >
>> > I think I will pass the request to kernel throught IOCTL call and wait
>> > for
>> > return.
>> > My kernel IOCTL function call
>> > KeWaitForSingleObject
>> >
>> > When interrupt happen, in ISR DPC, I will call
>> > KeSetEvent
>> >
>> > than my IOCTL function will return to user. Is this a good way to
>> > implement
>> > this? If not, what is the best way?
>> >
>> The overall concept is the best way, the implementation will not work.
>> First, have your IOCTL's put into a cancel safe queue (if this is WDF the
>> framework queue can do this for you, else look at IoCsqXXX functions),
>> then
>> have the IOCTL code return STATUS_PENDING from the function.
>>
>> The interrupt service routine needs to queue a DPC and then the DPC can
>> complete the IOCTL IRP.
>>
>> The application can then open the device with OVERLAPPED I/O and send
>> down
>> multiple requests if need be, which will then be processed in order. The
>> application can wait on an event associated with the IOCTL if it needs to
>> pend.
>>
>> Your approach had the following problems:
>>
>> 1. The application thread was blocked in the kernel so could not do
>> other work, this is not the Windows approach.
>
> ----> I still don't understand, even my IOCTL's put into a cancel safe
> queue, application also is blocked, isn't it? because it will not return
> to
> user, until I completed request, isn't it?

No, when you pend an IOCTL a STATUS_PENDING is returned to the application,
and depending on if it the call is overlapped or not, the task may proceed.

>> 2. Multiple threads would all get the same interrupt
>
>> 3. It is easy to miss interrupts since there is only one request
>> pending
>> 4. You cannot call KeSetEvent at interrupt level
> -----> Can I call KeSetEvent in EvtInterruptDpc , since it is at
> DISPATCH_LEVEL?
> from document, KeSetEvent is running at DISPATCH_LEVEL .

Yes DPC's are at DISPATCH_LEVEL and KeSetEvent is ok at DISPATCH

>> 5. You had no logic to reset the event so after the first interrupt
>> all
>> future requests return immediately
>>
>
> --------> Other question, if my default queue for IOCTL is
> WdfIoQueueDispatchSequential,
> can I still do OVERLAPPED I/O in IOCTL?
>
Yes.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply