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.gut...@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 _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
