Timur Tabi wrote:
Hi,
We have a PCI adapter that supports three different APIs / interfaces.
We're going to have a separate module for each interface. For
simplicity sake, I'll call these openib.ko, netdev.ko, and ccil.ko.
openib.ko will be in the drivers/inifiniband directory. netdev.ko will
be in the drivers/network directory. I don't know yet where we'll put
ccil.ko.
Excellent question - I look forward to learning the answer.
allow me to rephrase:
You have A,B,C, all of which want to own X
you suggest 3 alternatives:
(I answer in parens)
1. A,B,C are all independent.
this is inefficient cuz each has to look in detail at the card state to
determine
whether it should act upon the interrupt.
(IIUC, this is not interrupt-sharing per-se, but something else or is it?)
2. create P (parent), on which A,B,C are dependent
P has ISR code in it, A,B,C use that.
IOW, P export_symbols a register_isr_callback of some flavor,
A,B,C call it from their module_init()s (this is *the* dependency)
(this seems best. code is minimal, loaded footprint is probly also
close to minimal,
if only P+A are loaded, having P linked in statically is probly smaller.
One difficulty here is compiled-in vs loadable-module.
It seems simple to have them all the same - ie all modules, or all built-in.
I dont know how to do that with Kconfig depends statements.
having A be compiled, but B,C be loadable, makes for interesting
handling of P)
3. put ISR code M (for methods) in one of them , say A, so that B, C
use it.
thus B, C are dependent on A, since they use those exported symbols
(this seems best, *iff* you need other parts of A, but youve said you didnt.
it may come down to q of how big rest of A is, presumably the smallest
of the 3
(least kernel mem wasted on unused functionality) - this seems like a
poor criterion
for chosing which of ABC to put M code into.)
4, A,B,C each have copies of M
(I dont like this, I doubt real kernel folk will either. Its either
cut-paste (worse)
or a common .o file thats linked into each .ko (better - no cut-paste,
but..))
<related Q>
Is module loading/initialization safely serialized ?
if A, B are independent, and are simultaneously modprobed by 2 different
user-procs, is there locking to insure that one finishes before the
other is allowed to start ?
Assuming 2: given dependencies, P will load 1st, presumably 2nd
modprobe will
never try loading P, either cuz its locked out, or cuz it sees P inprogress.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
