On Wed, Dec 24, 2008 at 10:00 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
> On Wed, Dec 24, 2008 at 8:02 AM, Srinivas G.
> <srinivasg@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> Dear All
>>
>>
>>
>> Is there any concept of filter driver in case of Linux like in windows OS.
>> In windows we can write a filter driver to enhance the behavior of existing
>> driver and this filter driver can be attached to main driver either above or
>> below. But I don't see similar concept in Linux.
>>
>> Please advise.
>>
>> Srinivas G
>
> Can't see the forest for the trees?
>
> (for non-english speakers: I suspect you are missing the forest
> because of all the trees blocking your vision. :) )
>
> ==> Real answer
> The linux kernel is extremely "extensible".
>
> As you look at the code, you will see that much of the function
> invocation is table driven.
>
> ie.
> at init time:
>
> extern __process_data();
> .process_data = __process_data;
>
> Then at invocation time:
>
> .process_data(args)
>
> The concept is that if you need to modify the behavior of
> __process_data() you provide your own initializer that updates the
> .process_data field's value to point to a routine you provide:
>
> my_init()
> {
> extern my_process_data();
> .process_data = my_process_data;
> }
>
> my_process_data(args)
> {
> /* do my pre-filtering */
> ...
>
> /* Do default if needed */
> __process_data(args);
>
> /* do my post filtering */
> ...
>
> }
>
> Then at execution time my_process_data() gets invoked via the function
> pointer. And you as the author of my_process_data() can do anything
> you want.
>
> The concept is supported for both compiled in drivers and with run
> time loaded modules.
>
> Possibly a bigger issue is that the linux kernel is changing at a very
> high rate and the internal details needed to implement the above can
> and do change from time to time. AIUI, the linux kernel team makes no
> guarantees that your external module code will interface to the kernel
> in exactly the same way from one point release to the next.
>
> That is one reason it is highly recommended you get your code accepted
> into the vanilla kernel. At that point the overall linux team takes
> responsibility for updating your code if any of the low-level
> interface details change. (They don't always succeed, but they should
> try. Especially true if you implement a little used code path.)
>
> Greg
I've seen some of the other posts which imply you can just change the
source code, so no need for pre/post function calls.
I am most familiar with libata and I can assure you it is designed
explicitly to allow you to add pre and post call logic. It just works
as I describe in the email above.
In particular libata is designed to interface to SATA controllers.
The base libata core provides generic routines for interacting with
sata controllers. If the specific controller you are writing a driver
for needs a custom function, then you override the default. You have
the choice of providing a complete replacement for the generic
function, or you can wrap a call to the generic version with your own
pre / post call logic.
Greg
--
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
