Article 4199 of microsoft.public.win32.programmer.kernel:
In article <MPG.ef736fdae82e42989683@10.0.0.66>, Andyg@astondes.demon.co.uk (Andy) writes:
> I need to send a file (up to about 16Mb of data) to my driver, and get a 
> similar amount of data in return. There's a lot of passing of data to and 
> from a PCI card during this time, so I don't want to issue separate read 
> and write requests from the user process. Because I have large amounts of 
> data going in either direction I don't see any advantage of using 
> DIRECT_IO, as either BUFFERED or DIRECT IO will involve the setting up of 
> a large buffer in system space.

Um, no, DIRECT_IO doesn't - it just "pins" the buffer into physical 
memory.  Then you do MmGetSystemAddressForMdl, which sets up a second 
set of virtual addresses for the same physical pages as arre pointed 
to by the process page table entries. No second buffer, no buffer 
copy.

> If I avoid the use of ISRs, DPCs and the like, and do all of the 
> processing of the data in the Dispatch routine can I just use User mode 
> virtual addresses passed to the driver in a DeviceIoControl call? (or 
> have I missed something about - "running in the context of the user 
> thread"?).

Yes - as long as you can do all the processing in the dispatch
routine, and remember to protect all references to the process-psace
addresses with try...except.  

But this also requires that you never have to serialize access to your
device on behalf of multiple I/O requests.  That's what 
IoStart[Next]Packet are about.  Even if you never have to wait for an 
interrupt, if the access to the device is not a single atomic 
operation, you will probably have to use a Start I/O routine to 
serialize access to it -- unless you can guarantee that your app will 
never send you more than one I/O request at a time.

Note that GENPORT.C gets away with touching the I/O hardware from the 
dispatch routine for exactly this reason - the "I/O operation" it 
performs is a single reference to I/o space with no wait for 
interrupt.  If your operations aren't similarly simple, you'll need to 
serialize them, and that means IoStartPacket or a homegrown 
equivalent, and that means that IRPs that had to sit on the queue will 
be performed in arbitrary thread context... even if you never wait for 
an interrupt.

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
        Internet: jeh@cmkrnl.com (JH645)  CompuServe: 74140,2055  
drivers, internals, networks, applications, and training for VMS and Windows NT
NT driver FAQ, links, and other information:  http://www.cmkrnl.com/

If you post a reply in news, please don't e-mail it too.