The floppy uses a thread to process requests. The wait is done in the
context of the thread (PASSIVE_LEVEL). In this case, you can do some things
you can not normally do, but there is a serious performance hit when doing
this. The floppy device is so slow, it does not matter that it is being
processed in a thread; the device is far slower than the context switch
between the dispatch caller and the posting to the thread queue.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, February 16, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: RE: [ntdev] Storage drivers
Well in principle it’s a bad thing to do. Windows lets the caller
determine if they want the I/O request to be synchronous or asynchronous
- by blocking in the dispatching thread you’re forcing them into a
synchronous operation regardless of what they requested when they opened
the file.
It’s a bad idea in storage in particular for two reasons:
-
storage drivers (including the file systems) will dispatch I/O in
completion routines or timers which are typically running at dispatch
level. You can’t reliably block in your dispatch routine because you
might be at dispatch level.
-
when in the paging path you become part of a dependency chain where
improper blocking can result in a deadlock. For example, say the lock
you want is being held by a thread that’s trying to allocate memory,
which cause the system to try and clear some paged memory out which
causes a paging I/O to your device which blocks because of the lock
you’re holding.
In the case of the floppy driver it never becomes part of that
dependency chain. In the case of a read-only volume #2 also probably
doesn’t apply (until someone decides to use your driver in an embedded
system that boots from a hibernation file and caches writes in a filter
above your driver). But #1 still applies and it’s generally very hard
to figure out how your driver will be used after you’ve sold the
hardware.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joe Black
Sent: Monday, February 16, 2004 11:30 AM
To: Windows System Software Devs Interest List
Subject: RE: RE: [ntdev] Storage drivers
On Mon, 2004-02-16 at 12:38, Mark Roddy wrote:
In general this is bad practice in any Read/Write dispatch routine,
forget about storage drivers. What exactly are you trying to do that
you believe requires you to do a synchronous wait?
Any hardware that interrupts as a response to its command could work
with that model (perhaps not should, but could). What if you have 3
command/interrupt phases that you have to go through to service a read
or write?
I know there are other ways to do this, one of which you outline below,
but I’m more curious about the principle.
The storage sample drivers I browsed do not block on read/write
requests.
In the current DDK, in floppy.c, FloppyReadWrite (the dispatch handler
for IRP_MJ_READ) calls ExAcquireFastMutex.
Joe Black
Concerned about your privacy? Follow this link to get FREE encrypted
email: https://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434
Promote security and make money with the Hushmail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
