The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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?
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||30 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|
|Writing WDF Drivers||22 May 2023||Live, Online|