Mini-filter question

Is there a capability for forwarding a request to a different device stack
in a mini-filter? I am looking at a project that needs to send some
requests to a device object other than the volume I am filtering. In a
non-minifilter model this is easy, just call IoCallDriver with the desired
device object, but I see no way of doing this in a mini-filter without
rolling my own request. Since this is a performance critical path I am not
happy in doing this.

I would just do a legacy filter in this case, but I am concerned that
Micrsoft will turn around and say no-legacy filters at some point.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

Don,

In situations like this I roll up my own requests. For performance
critical pathways, pull the requests from a pool that is preallocated.
If it is for pre-create then you can use reparse processing, obviously.

As far as MS not supporting legacy filters, I doubt this will come into
play in the next few revisions of the OS, if ever. FM is a legacy filter
driver of sorts so they would need to completely rework how the
filesystem stack is implemented. And I doubt they have the cycles to do
this sort of redesign at the moment.

Pete

Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

Don Burn wrote:

Is there a capability for forwarding a request to a different device stack
in a mini-filter? I am looking at a project that needs to send some
requests to a device object other than the volume I am filtering. In a
non-minifilter model this is easy, just call IoCallDriver with the desired
device object, but I see no way of doing this in a mini-filter without
rolling my own request. Since this is a performance critical path I am not
happy in doing this.

I would just do a legacy filter in this case, but I am concerned that
Micrsoft will turn around and say no-legacy filters at some point.

What I am wondering is if there are good reasons why we cannot directly
obtain the underlying IRP from the minifilter callback data for purposes
like these.

/Daniel

“Don Burn” wrote in message news:xxxxx@ntfsd…
> Is there a capability for forwarding a request to a different device stack
> in a mini-filter? I am looking at a project that needs to send some
> requests to a device object other than the volume I am filtering. In a
> non-minifilter model this is easy, just call IoCallDriver with the desired
> device object, but I see no way of doing this in a mini-filter without
> rolling my own request. Since this is a performance critical path I am
> not happy in doing this.
>
> I would just do a legacy filter in this case, but I am concerned that
> Micrsoft will turn around and say no-legacy filters at some point.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>

“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> As far as MS not supporting legacy filters, I doubt this will come into
> play in the next few revisions of the OS, if ever. FM is a legacy filter
> driver of sorts so they would need to completely rework how the
> filesystem stack is implemented. And I doubt they have the cycles to do
> this sort of redesign at the moment.
>
Pete,

My concern is that they have mentioned the idea of not WHQL’ing them.
With Vista you can now WQHL any file system filter under unclassified. My
client has a strong need for the logo, due to their customer’s
requirements.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> What I am wondering is if there are good reasons why we cannot directly
> obtain the underlying IRP from the minifilter callback data for purposes
> like these.
>
Yes, I have wondered about the lack of a call to get the underlying IRP
such as what KMDF does. Barring that, I wonder why not a call like
FltPerformAsynchronousIo that allowed specification for a DEVICE_OBJECT.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

I suspect that if the minifilter is mandated, it would not be too hard for
Microsoft to simplify the filter manager so that it would not attempt to
hook into the file system stack at multiple points. This is used to
‘surround’ legacy filters and keep an order. It would also be possible for
them to have a system component not allow attach requests from any drivers
other than the filter manager itself. The development of DRM for the video
and audio stacks where each driver has to be signed with special signatures
or the stacks drops to the old ‘stupid’, ‘low quality’, ‘degraded’ mode.
The filter manager has so many hooks, I suspect they could just have it
unhook any other legacy filters. When you write the OS, many things can be
done.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Don Burn” wrote in message news:xxxxx@ntfsd…
>
> “Peter Scott” wrote in message
> news:xxxxx@ntfsd…
>>
>> As far as MS not supporting legacy filters, I doubt this will come into
>> play in the next few revisions of the OS, if ever. FM is a legacy filter
>> driver of sorts so they would need to completely rework how the
>> filesystem stack is implemented. And I doubt they have the cycles to do
>> this sort of redesign at the moment.
>>
> Pete,
>
> My concern is that they have mentioned the idea of not WHQL’ing them.
> With Vista you can now WQHL any file system filter under unclassified. My
> client has a strong need for the logo, due to their customer’s
> requirements.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>