Does layering of device drivers imply FDO + filter arrangement?

NTDEV
1

Dear all,

I have a simple NV RAM device, for which I wrote a driver. This driver simply allows reads/writes at a given offset from the start, within the addressable range.

Now, I would like to add another layer, that uses the simple device underneath, but builds a more complicated structure on top of it, like accessing a part of the storage space via a key. As I have 3 physical NV RAM devices, I need to be able to apply the new layer to a selected storage device only. It would be even better if the selection of the NV RAM device to be used with the new layer could be postponed for later and driven by an application.

What would be the best arrangement for this scenario? A filter driver? Could the filter driver be inserted into the device stack after the simple driver has been loaded and running?

Is it possible not to go down the filter driver path? Eg., just have a completely separate, software driver, that opens the simple device in an exclusive mode, and then implements the access functionality I want?

Thanks

2

Is your nv ram device a pnp device? If yes then generally filter drivers are not demand loaded but automatically loaded as part of the device pnp configuration. If instead your nv ram device is a legacy device (not pnp) then you can attach a filter driver on demand, in fact that is the only way to attach a filter driver.

Either approach (filter, separate software driver) works. Note that a filter does not have to be active - so the filter approach, especially in a pnp stack, simplifies configuration and installation and pnp/power state management, and leaves the base device unmodified until your application needs your new functionality.

3

Sorry for the late thanks - my post was somehow blocked for a while, or at least, I couldn’t see any of it