Do you know where I can find documentation or at least an example filter that loads at multiple altitudes and interacts between the instances for a given volume? I’ve run every search I can think of and have come up empty.
I need a presence at multiple altitudes, but the instances need to collaborate. For example, the upper instance needs to load information for filtering IRPs, and I would like to pass information from that instance to the lower instance so it doesn’t need to duplicate any effort. And for the best efficiency, I would really like to share stream contexts between the two instances.
I am able to track the instances through global variables, and FltCompareInstanceAltitudes() appears to allow me to determine which is upper and which is lower, but I’d like to be able to know when the instance is created which altitude it is.
Can I just use the upper instance from the lower instance when setting and getting contexts to share contexts?
What is the purpose of the DefaultContext option in the inf?
Can I pass something in the IRP to the lower filter?
CompletionContext only connects a given instance to its postop callback, right?
_Ron
There’s nothing that I’m aware of, but I Seem To Recall that it is a pretty obvious extension of just one.
And for the best efficiency, I would really like to share stream contexts between the two instances.
Can’t happen. A stream context has be attached to but one FileObject/FltInstance pair. They can point to each other of course but get your reference counting correct (if they point then they should have a reference to what they are pointed to, if both do it then they will never go away).
I’d like to be able to know when the instance is created which altitude it is
You should be able to get the name or altitude or some such from the instance. That should suffice - take a spin through the Fine Manual looking for FltQueryInstanceInfo or some such.
Can I pass something in the IRP to the lower filter?
Well there are ECP’s for IRP_MJ_CREATE but you have to be expect to see them more often than your expect in the face of STATUS_REPARSE or reissued operations.
The canonical method for cooperating drivers to communicate is internal ioctls.
You should bear in mind between one instance seeing a request and another instance it may have entirely changed. Different parameterization, different major or minor function, different file object, everything. Plus of course there will never be a 1-1 correspondence between requests at one instance and at another.
CompletionContext only connects a given instance to its postop callback, right?
I couldn’t imagine how it could work otherwise. I suggest you play with !fltkd.cbd on a recent Win10 system to see exactly what it available.
And for the best efficiency, I would really like to share stream contexts between the two instances.
They can point to each other of course but get your reference counting correct
So I assume I could use the other instance object to query its stream context in order to get that pointer to it, right? If so, I should be able to set theirs as well, and if I can do that, the driver could agree on which instance to use for contexts, and other than race conditions at startup/shutdown, could share contexts that way? I realize that the file objects could be changed in the middle and that IRPs could be added, or wholly replaced. I think I can deal with that. I just have one piece of information per file, and don’t want to duplicate it, and would like to avoid creating a central data manager/cache for it when the stream context suits that role perfectly.
I’d like to be able to know when the instance is created which altitude it is
You should be able to get the name or altitude or some such from the instance. That should suffice - take a spin through the Fine Manual looking for FltQueryInstanceInfo or some such.
I’ll give that a shot.
Can I pass something in the IRP to the lower filter?
Well there are ECP’s for IRP_MJ_CREATE but you have to be expect to see them more often than your expect in the face of STATUS_REPARSE or reissued operations.
The canonical method for cooperating drivers to communicate is internal ioctls.
I will take a look at this as well, thanks.
I couldn’t imagine how it could work otherwise. I suggest you play with !fltkd.cbd on a recent Win10 system to see exactly what it available.
Will do.
Thanks for the ideas, Rod
_Ron
I’ve decided that I can simplify this a ton by having the different instances run independently. Thus, I no longer have a need to pass information down the stack, nor to try to share contexts.
I do, however, need to determine at instance setup, which instance is which, or what altitude it is running at, so I know which job it should perform. This must be a very common need, but I have not found the answer. I tried searching for anything similar to FltQueryInstanceInfo, but came up empty handed. The minispy example uses 3 altitudes, but it doesn’t even have an InstanceSetup callback, and I can’t find anything in the code that differentiates the instances or altitudes.
The only thing I can think of at this point is recording each instance in a volume context and using FltCompareInstanceAltitudes() to figure out their pecking order, or test to see if they always load instance1, then instance2, etc., and use the initialization order to tell me which is which, but then I figure, why do we set an instance name if that name is not accessible. I tried ObQueryNameString() on a PFLT_INSTANCE, but my guess is that that function only works on objects whose name ends with _OBJECT. :neutral:
Any tips?
_Ron
Found it: FltGetInstanceInformation(). I apparently didn’t search for “instanceinfo” when I was in fltKernel.h.
Thanks for your help! I have what I need now.
_Ron