Sorry to jump in 
The final part "synchronicity games should be played by the OS alone ", ( and of course it is not really related to the thread as such ) is not what the current trend(s). Drivers are really extension to kernel ( not just to drive HW).
Frankly I’m scared to the idea, because we are all aware of the fact that “programmers should have options …” this was one of the marked difference between old school and modern school. This is also a very difficult choices for framework designers - we often call it capability to override.
This is to say “BTW, you don’t have to do anything if you agree with default behaviour, and of course you can override the behaviour if you are so willing …”. If you mean this, then I agree, otherwise I/O framework would be to strict.
Still I need to learn a bit about KMDF, but this is what I like about it.
-pro
----- Original Message -----
From: Alberto Moreira
To: Windows System Software Devs Interest List
Sent: Friday, November 16, 2007 7:44 PM
Subject: Re: [ntdev] Guarantee OVERLAPPED structure from user’s DeviceIoControl
I am a computer science dude, and I use those words in the standard fashion that academia uses them. Synchronous is this: the app only continues after the OS returns a status. Asynchronous, on the other hand, returns control immediately to the application, as soon as the request is caught by the OS: notification of completion reaches the app eventually, for example, in a queue or through a message; but the app doesn’t wait for it, except in the sense that the OS positively acknowledges the receipt of the request. Either way, I believe that this kind of thing should be no concern of the driver, it should be an issue between the app and the OS. The API between OS and driver should be pretty much transaction-like, one request demands one response; synchronicity games should be played by the OS alone, drivers are there to handle hardware!
Alberto.
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Thursday, November 15, 2007 11:00 PM
Subject: Re: [ntdev] Guarantee OVERLAPPED structure from user’s DeviceIoControl
Yes but you are simply redefining synchronous and asynchronous here from their common meaning within the Windows OS. Well behaved drivers either complete the request ‘immediately’ (for some value of immediately) in the dispatch routine, or mark the request pending and return pending status to the calling thread, completing the request at a later time. That latter behavior is commonly referred to as ‘asynchronous io’ and as the OP is confused enough, I don’t see the point of further confusing him by torturing the commonly understood meaning of these terms in this OS.
On Nov 15, 2007 9:24 PM, Alberto Moreira wrote:
Even if I issue an asynchronous request to a driver, I expect some kind of
positive acknowledgement to be returned to me in a synchronous way. If I
have to issue the request and then somehow wait till the response is
available, that’s not what I’d call asynchronous either. Point being, I
believe that a driver should consider all user requests as synchronous, in
the sense that the user deserves an immediate response - even if that
response is, hang on because it’s going to take time before I give your
answer back.
The good way of thinking about a user-driver api is that of a virtual
machine - pretend that the app is the only thread running, that all calls to
the driver are synchronous - and if the OS wants to asynchronize it, their
problem, but please do not involve the application in it.
A user level app should be able to pretend it’s the only thread running on
the machine. After all, the whole point of having an OS there is to make
sure that applications can be blissfully ignorant of other applications
running concurrently, or of what gyrations the OS has to go through to make
it happen!
In other words, I believe that all app-driver interactions should be
considered as essentialy synchronous unless one cannot possibly avoid doing
it otherwise.
Alberto.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List” < xxxxx@lists.osr.com>
Sent: Thursday, November 15, 2007 5:01 PM
Subject: Re: [ntdev] Guarantee OVERLAPPED structure from user’s
DeviceIoControl
> xxxxx@rtd.com wrote:
>> Well, I am under the impression that it is a no-no to use synchronous
>> IOCTL calls on a device file with FILE_FLAG_OVERLAPPED.
>
> What do you mean by “synchronous IOCTL calls”? Do you mean an ioctl
> that a driver blocks instead of pending? If so, then there’s nothing
> architecturally wrong with that. It might be unexpected, but it’s
> perfectly legal.
>
> An application can’t make a non-overlapped DeviceIoControl call on a
> file handle opened with FILE_FLAG_OVERLAPPED. That’s an application
> error. The documentation says that it “fails in unpredictable ways”.
>
>> If that is the case, I would like to be able to refuse/fail any IOCTL not
>> called with an OVERLAPPED structure in order to prevent misuse of the
>> driver.
>>
>
> A driver should never worry about how it was called. It should assume
> that every request is asynchronous. If a request can be completed
> quickly, then complete it. Otherwise, mark it pending.
>
> –
> 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
—
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
–
Mark Roddy — 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
—
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