CDO vs. Filter Communication Port Object

NTFSD
1

NTFSD Folk:

I’ve implemented a minifilter and communicate with user-mode stuff using a
Control Device Object (CDO) and DeviceIoControl functions. It works very
nicely.

I haven’t fooled with the Filter Communication Port Object, although it’s
created and initialized in my driver. This seems to be the “recommended”
way to talk to a minifilter.

What are the pros/cons of one vs. the other? Is it worth changing over?

IOW, my current driver ain’t broke, but should I try to fix it anyhow?

Thanks,
Ken

2

Ken,

I believe some of the advantages of using the new filter communication
model are:

  • It is simpler to use then a CDO
  • As we make improvements (performance, scalability, etc) you will
    automatically benefit from them.

If you are converting a current filter to a mini-filter and want a CDO
so you don’t have to modify your user mode component; that is a very
good reason for keeping your CDO. We have internal minifilters that
have a CDO for this exact reason. Because of this we have added a new
sample minifilter to the IFSKit that shows how to create and use a CDO.

So the answer is: use what works best for your situation.

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 Ken Cross
Sent: Monday, October 25, 2004 4:54 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] CDO vs. Filter Communication Port Object

NTFSD Folk:

I’ve implemented a minifilter and communicate with user-mode stuff using
a
Control Device Object (CDO) and DeviceIoControl functions. It works
very
nicely.

I haven’t fooled with the Filter Communication Port Object, although
it’s
created and initialized in my driver. This seems to be the
“recommended”
way to talk to a minifilter.

What are the pros/cons of one vs. the other? Is it worth changing over?

IOW, my current driver ain’t broke, but should I try to fix it anyhow?

Thanks,
Ken

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

3

A couple more key advantages of using the communication port object:

  1. You get security for free (and it is non-trivial to get this
    right) - i.e. you just supply the ACL and the channel will be secured
    appropriately for you
  2. Unload: this is unload safe. You can unload your driver while
    there are channels open (user mode will get disconnects & the pending
    messages get flushed out), so the user mode can never hold up your
    unload (as it can if you use the CDO approach since you can’t unload as
    long as there was an outstanding open on the CDO). Makes it easier to
    upgrade your driver independent of the user process.

Yes it goes without saying- if you want to hold off on changing your
user mode component you should continue to use the CDO. You will need to
change both user mode (if you already have abstracted the communications
to the driver in some way, then it becomes quite easy) and the filter to
take advantage.

Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neal Christiansen
Sent: Tuesday, October 26, 2004 1:16 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] CDO vs. Filter Communication Port Object

Ken,

I believe some of the advantages of using the new filter communication
model are:

  • It is simpler to use then a CDO
  • As we make improvements (performance, scalability, etc) you will
    automatically benefit from them.

If you are converting a current filter to a mini-filter and want a CDO
so you don’t have to modify your user mode component; that is a very
good reason for keeping your CDO. We have internal minifilters that
have a CDO for this exact reason. Because of this we have added a new
sample minifilter to the IFSKit that shows how to create and use a CDO.

So the answer is: use what works best for your situation.

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 Ken Cross
Sent: Monday, October 25, 2004 4:54 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] CDO vs. Filter Communication Port Object

NTFSD Folk:

I’ve implemented a minifilter and communicate with user-mode stuff using
a Control Device Object (CDO) and DeviceIoControl functions. It works
very nicely.

I haven’t fooled with the Filter Communication Port Object, although
it’s created and initialized in my driver. This seems to be the
“recommended”
way to talk to a minifilter.

What are the pros/cons of one vs. the other? Is it worth changing over?

IOW, my current driver ain’t broke, but should I try to fix it anyhow?

Thanks,
Ken

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

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com