An intermediate driver must agree with the next-lower driver's device
object about DO_DIRECT_IO or DO_BUFFERED_IO, but a highest-level
driver (FSD?) is allowed to use whatever buffering method it wants or
neither. Does this mean that if an FSD is using neither I/O, before
it passes an IRP to a driver below it that wants DO_BUFFERED_IO, the
FSD has to do the validity checking, alignment guarantee, and memcopy
before/after to make the lower driver happy?

I was initially confused by the implication that one driver in a stack
could use whatever buffering method it wants and wondered how that
could be reconciled with passing IRPs down the stack to other drivers
that might use a different buffering method.

Re: Matching device object buffering flags by Maxim

Maxim
Thu Oct 12 18:30:35 CDT 2006

> An intermediate driver must agree with the next-lower driver's device
> object about DO_DIRECT_IO or DO_BUFFERED_IO, but a highest-level
> driver (FSD?) is allowed to use whatever buffering method it wants or
> neither.

Cached IO of the FSD is always NEITHER, noncached is always DIRECT (unless it
is a cached IO with immediate flush just after).

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


Re: Matching device object buffering flags by BubbaGump

BubbaGump
Thu Oct 12 18:55:42 CDT 2006

On Fri, 13 Oct 2006 03:30:35 +0400, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:

>> An intermediate driver must agree with the next-lower driver's device
>> object about DO_DIRECT_IO or DO_BUFFERED_IO, but a highest-level
>> driver (FSD?) is allowed to use whatever buffering method it wants or
>> neither.
>
>Cached IO of the FSD is always NEITHER, noncached is always DIRECT (unless it
>is a cached IO with immediate flush just after).

That wasn't my question, but does the driver model stipulate those
buffering methods with relation to caching, or does "always" mean
"usually"?


Re: Matching device object buffering flags by Peter

Peter
Thu Oct 12 20:13:08 CDT 2006

An FSD won't have to worry about a lower driver that only accepts buffered
I/O. The FSD loads on the disk stack and direct I/O is part of the contract
there.

When the FSD does cached I/O it triggers a page-in through the memory
manager which causes an uncached I/O to be sent. When the FSD does uncached
I/O it builds an MDL for the buffers before sending them down.

Drivers which try to live in between two other drivers that have an
established contract must match that contract. If the contact is buffered
then they need to be buffered. If it's direct then they need to be direct.
For storage the contract is direct.

-p


"BubbaGump" wrote in message
news:ksfti21u5g7pkkr0bgjbsjnheq2iplf74q@4ax.com...
> An intermediate driver must agree with the next-lower driver's device
> object about DO_DIRECT_IO or DO_BUFFERED_IO, but a highest-level
> driver (FSD?) is allowed to use whatever buffering method it wants or
> neither. Does this mean that if an FSD is using neither I/O, before
> it passes an IRP to a driver below it that wants DO_BUFFERED_IO, the
> FSD has to do the validity checking, alignment guarantee, and memcopy
> before/after to make the lower driver happy?
>
> I was initially confused by the implication that one driver in a stack
> could use whatever buffering method it wants and wondered how that
> could be reconciled with passing IRPs down the stack to other drivers
> that might use a different buffering method.
>


Re: Matching device object buffering flags by BubbaGump

BubbaGump
Thu Oct 12 20:27:11 CDT 2006

Okay.




On Thu, 12 Oct 2006 18:13:08 -0700, "Peter Wieland [MSFT]"
<peterwie@online.microsoft.com> wrote:

>An FSD won't have to worry about a lower driver that only accepts buffered
>I/O. The FSD loads on the disk stack and direct I/O is part of the contract
>there.
>
>When the FSD does cached I/O it triggers a page-in through the memory
>manager which causes an uncached I/O to be sent. When the FSD does uncached
>I/O it builds an MDL for the buffers before sending them down.
>
>Drivers which try to live in between two other drivers that have an
>established contract must match that contract. If the contact is buffered
>then they need to be buffered. If it's direct then they need to be direct.
>For storage the contract is direct.
>
>-p
>
>
>"BubbaGump" wrote in message
>news:ksfti21u5g7pkkr0bgjbsjnheq2iplf74q@4ax.com...
>> An intermediate driver must agree with the next-lower driver's device
>> object about DO_DIRECT_IO or DO_BUFFERED_IO, but a highest-level
>> driver (FSD?) is allowed to use whatever buffering method it wants or
>> neither. Does this mean that if an FSD is using neither I/O, before
>> it passes an IRP to a driver below it that wants DO_BUFFERED_IO, the
>> FSD has to do the validity checking, alignment guarantee, and memcopy
>> before/after to make the lower driver happy?
>>
>> I was initially confused by the implication that one driver in a stack
>> could use whatever buffering method it wants and wondered how that
>> could be reconciled with passing IRPs down the stack to other drivers
>> that might use a different buffering method.
>>