Perhaps a better way of asking the question would be “Why might I not be
able to use METHOD_NEITHER when passing data between an application and a
driver?”
I am developing a driver which provides an application with access to a
BusMaster device on the PCI bus. The driver is specific to this
application. The application makes a call to a DLL and the DLL calls
DeviceIoControl(). My understanding is that this causes the IO Manager to
perform the necessary buffer locking/copying and then builds an IRP in
nonpaged space. It is my understanding that the IO Manager then calls my
driver.
Since my driver is only ever called in this way (not from another driver),
it is my understanding that it will be running in the context of the
application and at IRQL PASSIVE_LEVEL. (Is this true?) Consequently, I
believe that it is safe to use the virtual addresses that METHOD_NEITHER
would provide.
So what things might make it impossible to use METHOD_NEITHER?
Well, I guess that if my driver responds to an interrupt then this may not
run in the context of the original application. (Is that true?) In itself,
this may not prevent the use of METHOD_NEITHER, but those parts of the
driver that were called by the ISR could not expect the passed virtual
addresses to be either valid or currently paged into memory. (And since I
expect that such routines run at quite a high IRQL, any page faults are
likely to raise an exception.) However, if the parts of the driver that
were running in the context of the calling process made sure that any
buffers referred to by the ISR were locked down and either moved to
nonpaged space or represented in physical memory space by an MDL, then I
could still use METHOD_NEITHER, couldn’t I?
My driver does not service any interrupts, but as part of the mapping
operation, I have use an AdapterControl() callback routine. I’d guess that
this similar to an ISR in that it is run at a high IRQL and may not be
running in the context of the calling process. So, as long as the part of
my driver that is called by the application (via the DLL) locks down any
buffers that are referred to by the callback routine, I should be okay,
shouldn’t I?
[This also suggests to me that any communication with the callback
routine, e.g. the data pointed to by the context parameter, needs to be in
non-paged space, something that I had overlooked.]
My driver also uses KeDelayExecutionThread(). Although this is likely to
cause a reschedule, and therefore a context switch, I would expect the
original context to be restored when execution resumes. So this should not
influence the suitability of METHOD_NEITHER, should it?
I hope that all made sense. Sorry that it is so longwinded.
METHOD_NEITHER is very attractive, because it allows the application (via
the DLL) to pass data by reference rather than solely by value.
Consequently, it can handle the case where I want to pass multiple blocks
of data in both directions without the need to make them contiguous in
virtual memory space.
If I am way off the mark, or if this has already been covered somewhere,
then I apologise. I admire the patience of anyone who has read this far.
I would greatly appreciate any clarification that anyone can provide.
Many thanks,
Richard
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com