A few more questions

1. If I want to put a thread to sleep in KMDF, what mechanisms can I use?
E.g., lets say EvtIoRead callback is called, yet the hardware resources to
process that are not available yet. I want EvtIoRead to go to sleep until
its woken up by the ISR. In Linux kernel there are wait queues that a
function can sleep on until woken up. Are there similar native constructs
in KMDF, or if not, can I use WDM (if they are available) or WIN32 calls?
Anything besides WaitLock? (WaitLock doesn't seem do just that, as it forces
the code that acquires it to execute as a critical section, AFAIK)

2. Let say the immediate availability of hardware for a DMA depends on how
many scatter-gather elements are in the request and the current state of
hardware due to outstanding requests. I.e., if I follow the framework, I
won't know how many scatter-gather elements are in the request until I am
inside EvtProgramDma callback. If at that point the resources are not
available, I would need to wait for their availability. So:

a) EvtProgramDma runs at DISPATCH IRQL, which means that even WaitLock
cannot be executed in blocking mode. If the hardware resources are not
immediately available, what should the driver do at this point? Spinning for
them seems like a huge waste of processor cycles.

b) Alternatively, I could postpone DmaExecute until all the resources are
available and spin on that in the Io callback at passive IRQL (see quesetion
1). However, is there a way to infer how many items will be in the
scatter-gather list at that point? Is (request_size/PAGE_SIZE+1) a definite
upper bound?

Re: Waiting in KMDF by Don

Don
Wed Jul 04 09:11:04 CDT 2007


"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:072AAA70-EF5C-471B-9F73-9559B5FE8C06@microsoft.com...
>A few more questions
>
> 1. If I want to put a thread to sleep in KMDF, what mechanisms can I
> use?
> E.g., lets say EvtIoRead callback is called, yet the hardware resources
> to
> process that are not available yet. I want EvtIoRead to go to sleep
> until
> its woken up by the ISR. In Linux kernel there are wait queues that a
> function can sleep on until woken up. Are there similar native
> constructs
> in KMDF, or if not, can I use WDM (if they are available) or WIN32 calls?
> Anything besides WaitLock? (WaitLock doesn't seem do just that, as it
> forces
> the code that acquires it to execute as a critical section, AFAIK)

Putting threads to sleep for I/O is not appropriate in Windows, this is a
Unix thing. You pend the request and then let DPC from the ISR process
things further.

I am not a DMA expert so I will defer the remaining questions to others.


--
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: Waiting in KMDF by Maxim

Maxim
Wed Jul 04 12:08:00 CDT 2007

> Putting threads to sleep for I/O is not appropriate in Windows, this is a
> Unix thing. You pend the request and then let DPC from the ISR process
> things further.

I think you are referring to waiting for request completion. I was asking
about request initiation. Even if I through requests in a FIFO and let the
DPC both complete oustanding requests and start new ones, sooner or later
FIFO might fill up, at which point I would need to wait before I could put
more stuff into the FIFO. I.e. sooner or later I would still need to either
wait or spin.

Re: Waiting in KMDF by Don

Don
Wed Jul 04 12:53:53 CDT 2007

NO, NO, NO!!!! You need to queue the requests as they arrive to your
driver, when a hardware FIFO comes available you take the request of the
WDF queue for processing. You hand the request to the hardware, and enque
the request for completion, then when the interrupt indicates the hardware
has completed the request, you deque and complete the request.


--
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

"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:A18400BF-5625-4468-BA45-D5BEBBB7E189@microsoft.com...
>> Putting threads to sleep for I/O is not appropriate in Windows, this is
>> a
>> Unix thing. You pend the request and then let DPC from the ISR process
>> things further.
>
> I think you are referring to waiting for request completion. I was
> asking
> about request initiation. Even if I through requests in a FIFO and let
> the
> DPC both complete oustanding requests and start new ones, sooner or later
> FIFO might fill up, at which point I would need to wait before I could
> put
> more stuff into the FIFO. I.e. sooner or later I would still need to
> either
> wait or spin.



Re: Waiting in KMDF by Maxim

Maxim
Wed Jul 04 19:00:00 CDT 2007

> NO, NO, NO!!!! You need to queue the requests as they arrive to your
> driver, when a hardware FIFO comes available you take the request of the
> WDF queue for processing. You hand the request to the hardware, and enque
> the request for completion, then when the interrupt indicates the hardware
> has completed the request, you deque and complete the request.

Ok, so lets say the requests are queued. What does the function that moves
them into hardware for processing look like? Does it reside in the same ISR
that performs request completions? (If so, that makes for one strange
design, but ok) If it doesn't reside in the ISR, it has to somehow wait for
hardware to become available before it sends a request to hardware. I.e., it
has to spin on the hardware status, in either blocking or non-blocking
fashion.

Re: Waiting in KMDF by Don

Don
Wed Jul 04 19:21:35 CDT 2007

"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:998BD06E-946E-4D22-8CED-3D47D59F7232@microsoft.com...
>> NO, NO, NO!!!! You need to queue the requests as they arrive to your
>> driver, when a hardware FIFO comes available you take the request of the
>> WDF queue for processing. You hand the request to the hardware, and
>> enque
>> the request for completion, then when the interrupt indicates the
>> hardware
>> has completed the request, you deque and complete the request.
>
> Ok, so lets say the requests are queued. What does the function that
> moves
> them into hardware for processing look like? Does it reside in the same
> ISR
> that performs request completions? (If so, that makes for one strange
> design, but ok) If it doesn't reside in the ISR, it has to somehow wait
> for
> hardware to become available before it sends a request to hardware.
> I.e., it
> has to spin on the hardware status, in either blocking or non-blocking
> fashion.

It is not in the ISR, typically it is in the DPC related to the ISR. The
ISR typically disables the interrupts, collects hardware state and queues a
DPC. The DPC processes the interrupt (i.e. completes the request related to
the hardware), re-enables interupts and submits a new request if there is
one available. Yes you need a mechanism for determining if the request can
be submitted or needs to be queued.

Take a look at the samples in KMDF and get the WDF book and read it. You
do not have the basics of Windows yet.


--
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: Waiting in KMDF by Maxim

Maxim
Thu Jul 05 06:04:18 CDT 2007

> Ok, so lets say the requests are queued. What does the function that moves
> them into hardware for processing look like? Does it reside in the same ISR
> that performs request completions? (If so, that makes for one strange
> design, but ok)

Same DPC that performs request completions.

>If it doesn't reside in the ISR, it has to somehow wait for
> hardware to become available before it sends a request to hardware. I.e., it
> has to spin on the hardware status, in either blocking or non-blocking
> fashion.

No. "Hardware becomes available" is some event, raised by some code. This very
code will also fires this function.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


Re: Waiting in KMDF by Maxim

Maxim
Thu Jul 05 07:06:03 CDT 2007

Thanks for answering my questions precisely.

But in general terms, are blocking waits ever used in WDF? I mean, there is
obviously KMDF WaitLock which blocks, and then there are kernel functions
like KeWaitForSingleObject and kernel mutex/semaphore/event objects. Can
those be used in KMDF, and if so, what is a general rule for when to use
them? (E.g., can you only use them if the thread context is known?)

Thanks again

"Maxim S. Shatskih" wrote:

> > Ok, so lets say the requests are queued. What does the function that moves
> > them into hardware for processing look like? Does it reside in the same ISR
> > that performs request completions? (If so, that makes for one strange
> > design, but ok)
>
> Same DPC that performs request completions.
>
> >If it doesn't reside in the ISR, it has to somehow wait for
> > hardware to become available before it sends a request to hardware. I.e., it
> > has to spin on the hardware status, in either blocking or non-blocking
> > fashion.
>
> No. "Hardware becomes available" is some event, raised by some code. This very
> code will also fires this function.


Re: Waiting in KMDF by Don

Don
Thu Jul 05 07:17:32 CDT 2007


"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:0BA86041-2AD2-40C7-974B-FC8159828FEB@microsoft.com...
> Thanks for answering my questions precisely.
>
> But in general terms, are blocking waits ever used in WDF? I mean, there
> is
> obviously KMDF WaitLock which blocks, and then there are kernel functions
> like KeWaitForSingleObject and kernel mutex/semaphore/event objects. Can
> those be used in KMDF, and if so, what is a general rule for when to use
> them? (E.g., can you only use them if the thread context is known?)
>
Yes you can use them, but waiting in a user space thread requesting general
I/O is a very bad idea. Windows is built around the concept of
asynchronous I/O and using a wait turns this synchronous. You typically
use waits to acquire synchronization mechanisms to access common data
structures, or in kernel threads the driver creates.

Even without your refererence to Linux, it is obvious that you cam from a
Unix/Linux model, where waiting is used a lot. The Windows model assumes
you either complete I/O requests quickly or mark the request as pending and
let the application continue working. This is also true of interrupts, the
assumption is you service the interrupt quickly, and then let the DPC do
most of the work.


--
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: Waiting in KMDF by Maxim

Maxim
Thu Jul 05 08:56:01 CDT 2007


Thanks. Ok, studying chapter 15 in the WDF book, somehow I missed it before
:)

> Yes you can use them, but waiting in a user space thread requesting general
> I/O is a very bad idea. Windows is built around the concept of
> asynchronous I/O and using a wait turns this synchronous. You typically
> use waits to acquire synchronization mechanisms to access common data
> structures, or in kernel threads the driver creates.
>
> Even without your refererence to Linux, it is obvious that you cam from a
> Unix/Linux model, where waiting is used a lot. The Windows model assumes
> you either complete I/O requests quickly or mark the request as pending and
> let the application continue working. This is also true of interrupts, the
> assumption is you service the interrupt quickly, and then let the DPC do
> most of the work.
>
>
> --
> 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
>
>
>