I've tracked down what happens on Windows in the debugger, and the
relevant device objects don't have DO_DIRECT_IO set.
The WDK sample FS drivers use neither I/O as well.
I'm not 100% sure but from what I saw this part of our I/O manager
implementation is identical to Windows's and there's no chaining
happening. However a test to prove that is certainly a good idea. I'll
have a look at adding that.
The fastfat code is already agnostic to the I/O type pretty much
everywhere, it simply uses SystemBuffer if MdlAddress is NULL. However
my verification here was really just "it still works" (since it
"should" simply lead to obvious crashes otherwise).
I'm pretty much just dragging fastfat along right now while fixing
other things, so if there are any bugs I'm introducing there, I'm happy
to hear about them. But "properly" fixing fastfat is rather far in the
future on my agenda, if at all. :\
Thanks,
Thomas
On 2014-08-27 20:12, cameron.gutman(a)reactos.org wrote:
This seems strange. I understand that NT 5.x has a
limitation of 64 MB MDLs on x86, but direct I/O was designed for exactly this case of
large I/O operations. Has anyone verified that 2k3 doesn’t do MDL chaining for direct I/O
when the transfer is larger than a single MDL can hold?
Also aren’t there changes to the IRP dispatch routines required to cope with not having
an Irp->MdlAddress pointer anymore?
Cameron