Hi Bob and ntfs fellows,
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.
imho it seems that >filter< is not really the correct term (though
used by ms) for the way things are implemented in nt. I would define
this mechanism more as a >hook< which allows you to intercept messages
directed to some recipient. It’s on the >hook< to decide what should
happen with the message then. The message can be passed along (maybe
modified) to the original recipient, but also may just be completed or
passed to whomever the >hook< wants it to pass to.
The point here is: the >hook< can just specify for who he wants to intercept
messages, but can’t specify the sender of the messages. So there is no way
to
insert< a filter, just to >hook< a recipient.
And you HAVE TO hook the recipient BEFORE any driver of which you are
interested in messages from retrieves a pointer to your recipient.
And also, how do I deal with this behavior in my attempts to
attach to the
IDE driver ?
You MUST hook the IDE driver first, before other drivers retrieve
a pointer to the IDE driver. You do that, then they will get a pointer
to your >filter<.
I hope this helps. Of course, a real filter concept would be a much
more nice thing.
Radek Liba
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