To my understanding, IoGetRelatedDeviceObject will return the highest level
device in the file system driver stack (assuming I am passing it a File
Object that relates to the file system driver stack).
I am trying to use this call to prepare an irp for a lower level driver
call. but it the device object i get back is the at the top of the file
system driver stack i run the risk of passing it back through my own filter
driver. what is the proper manner to get around this issue?
thanks! - jb
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You’ll probably want to tuck away a pointer to the next lower device
in the device extension for your filter.
-Joel
-----Original Message-----
From: xxxxx@earthlink.net [mailto:xxxxx@earthlink.net]
Sent: Tuesday, January 23, 2001 8:51 AM
To: File Systems Developers
Subject: [ntfsd] IoGetRelatedDeviceObject
To my understanding, IoGetRelatedDeviceObject will return the highest level
device in the file system driver stack (assuming I am passing it a File
Object that relates to the file system driver stack).
I am trying to use this call to prepare an irp for a lower level driver
call. but it the device object i get back is the at the top of the file
system driver stack i run the risk of passing it back through my own filter
driver. what is the proper manner to get around this issue?
thanks! - jb
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> I am trying to use this call to prepare an irp for a lower level driver
call. but it the device object i get back is the at the top of the file
system driver stack i run the risk of passing it back through my own
filter
driver. what is the proper manner to get around this issue?
When you have attached to the lower device object, you have obtained and
saved the lower device object pointer. Use it to send IRPs to.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>>
You’ll probably want to tuck away a pointer to the next lower device
in the device extension for your filter.
<<<
This sort of beahvior appears to be exactly the thing that is causing me a
problem.
I suspect this sort of behavior to be against the nice idea of a layered IO
architecture, where anybody is supposed to be able to insert a new filter of
some kind at any point, and intercept all IRP flow between the two drivers of
interest. I therefore ask this group what they think. I suspect caching a
pointer to the next level lower driver is common practice, but to me it seems
wrong.
In my case, I am trying to insert a filter driver somewhere in the layers of
disk drivers. I wish to intercept all IO going to IDE. I want to catch any
attempts to perform IO (non-cached, async) to an odd byte memory address. I
want to perform this IO to my own aligned buffer, and then to copy the data
off to the actual target buffer.
I have tried attaching to various disk related drivers, but in some cases
this caching of a pointer to the lower driver causes IRPs to bypass my
filter. The driver above me sends IRPs directly to the driver below me, via
the pointer to it that it has cached. Also, some drivers cache a pointer to
lower drivers in a VPB.
It seems to me that there should be a better way to do this. The IO manager
should control who sends what where. Isn’t there just a way to say ‘send
this onwards, to those below me’ ? Or must you always specify a destination ?
And also, how do I deal with this behavior in my attempts to attach to the
IDE driver ?
Thanks
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com