[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1282570983.2605.1832.camel@laptop>
Date: Mon, 23 Aug 2010 15:43:03 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jan Engelhardt <jengelh@...ozas.de>
Cc: Brian Gerst <brgerst@...il.com>, aijazbaig1@...il.com,
netfilter-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: help needed with EXPORT_SYMBOL
On Mon, 2010-08-23 at 15:32 +0200, Jan Engelhardt wrote:
> On Monday 2010-08-23 15:17, Peter Zijlstra wrote:
>
> >On Mon, 2010-08-23 at 07:48 -0400, Brian Gerst wrote:
> >>
> >> Use an exported function pointer in the main kernel as a hook that the
> >> module sets when it is loaded. Note, you must use module_get and
> >> module_put around the call to the module to prevent it from unloading
> >> while in use.
> >
> >Please don't do any such thing, its impossible to use correctly.
> >
> >Suppose there are two modular users, A and B.
>
> Though in case there is just a single user it can work out.
> Just like bridge.c, and the bunch of nf_nat_*.c. :-)
> Though yeah. Bad bad.
We have this problem in several areas in the kernel (pm_idle being the
one I hate most since its in code I touch actually grew tons of users).
If you really need to export hooks, provide a registration mechanism and
an arbiter. A very simple, already existing, implementation of this
would be notification chains (include/linux/notifier.h), these provide a
registration interface, and the arbiter is a combination of static
priority combined with return codes.
A more complex example would be the cpuidle/pm_qos subsystem, where you
can register idle states and provide various attributes (exit latency,
energy break even duration, etc) and have the governor pick an idle
state depending on the predicted idle time and required exit latencies.
Bare function pointers suck.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists