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
--
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
