Hi,
I have an older filter driver that I’m trying to update. The new driver
uses FltCreateCommunicationPort/FltSendMessage for some of its
operation… this is working. However I need to be able to control it
with IOCTL commands to mimic the behaviour of the old driver.
Since by an accident of history both ‘old’ and ‘new’ drivers have the
same name (the new was supposed to replace the old, then it got shelved,
now I have about 3 days to get them merged… sigh…). It seems to me
that I’m hosed - The communication port cannot also have IOCTLs sent to
it, since you can’t do CreateFile on it (??? I imply from the docs that
these are handles to entirely different objects, so DeviceIoControl will
never work).
Since I’d rather not rewrite all the userspace client code too is there
a way to achieve this?
Tony
I don’t think it would take lot of time to replace DeviceIoControl with
FilterSendMessage/FilterGetMessage/FlterReplyMessage functions.
MessageNotifyCallback in kernel mode has the similar input/output parameters
like your legacy filter for irp_mj_device_control - so the code behind your
ioctl commands would be same for both drivers.
-pk
“Tony Hoyle” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I have an older filter driver that I’m trying to update. The new driver
> uses FltCreateCommunicationPort/FltSendMessage for some of its operation…
> this is working. However I need to be able to control it with IOCTL
> commands to mimic the behaviour of the old driver.
>
> Since by an accident of history both ‘old’ and ‘new’ drivers have the same
> name (the new was supposed to replace the old, then it got shelved, now I
> have about 3 days to get them merged… sigh…). It seems to me that I’m
> hosed - The communication port cannot also have IOCTLs sent to it, since
> you can’t do CreateFile on it (??? I imply from the docs that these are
> handles to entirely different objects, so DeviceIoControl will never
> work).
>
> Since I’d rather not rewrite all the userspace client code too is there a
> way to achieve this?
>
> Tony
>
>
>
>
>
Petr Kurtin wrote:
I don’t think it would take lot of time to replace DeviceIoControl with
FilterSendMessage/FilterGetMessage/FlterReplyMessage functions.
MessageNotifyCallback in kernel mode has the similar input/output
parameters like your legacy filter for irp_mj_device_control - so the
code behind your ioctl commands would be same for both drivers.
Unfortunately DisconnectNotifyCallback is called with the connection
cookie *not* the port cookie, making such use rather difficult - I
really need to know when a client closes as I’m storing state for them
(and having a close message won’t work in the long term, since in the
real world clients don’t always die cleanly).
There are also reasons for not changing the API… looks like I’ll have
to bite the bullet and change the name of the communication port so I
can create a proper device symbolic link for the old name (less work -
there’s legacy code there I can’t disturb. Still pushes me past
deadline, but, well, reality always trumps deadlines in my opinion).
Tony
> Petr Kurtin wrote:
> I don’t think it would take lot of time to replace DeviceIoControl
> with FilterSendMessage/FilterGetMessage/FlterReplyMessage functions.
> MessageNotifyCallback in kernel mode has the similar input/output
> parameters like your legacy filter for irp_mj_device_control - so
the
> code behind your ioctl commands would be same for both drivers.
Unfortunately DisconnectNotifyCallback is called with the connection
cookie *not* the port cookie, making such use rather difficult - I
really need to know when a client closes as I’m storing state
for them (and having a close message won’t work in the long term,
since in the
real world clients don’t always die cleanly).
How 'bout if the ‘connection cookie’ was simply a pointer to a structure
that contained the ‘port cookie’?
Tony,
One of the samples in the IFSKit is called “cdo”. This samples shows
how a minifilter can still have a control device object for private
communication via FSCTLs.
There are times (like you described) where you can’t (or don’t want to)
change your existing usermode communication using FSCTLs. This shows
you how to do this.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Wednesday, March 22, 2006 3:11 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Sending IOCTL to a minifilter
Petr Kurtin wrote:
I don’t think it would take lot of time to replace DeviceIoControl
with
FilterSendMessage/FilterGetMessage/FlterReplyMessage functions.
MessageNotifyCallback in kernel mode has the similar input/output
parameters like your legacy filter for irp_mj_device_control - so the
code behind your ioctl commands would be same for both drivers.
Unfortunately DisconnectNotifyCallback is called with the connection
cookie *not* the port cookie, making such use rather difficult - I
really need to know when a client closes as I’m storing state for them
(and having a close message won’t work in the long term, since in the
real world clients don’t always die cleanly).
There are also reasons for not changing the API… looks like I’ll have
to bite the bullet and change the name of the communication port so I
can create a proper device symbolic link for the old name (less work -
there’s legacy code there I can’t disturb. Still pushes me past
deadline, but, well, reality always trumps deadlines in my opinion).
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com