[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

So just how are out of tree kernel modules supposed to work now?



I am starting to think that debian has completely broken support for
compiling out of tree kernel modules as of 2.6.29 now.

It used to be, that if you needed to know if a certain function used one
style or another, then you could do a compile test against the kernel
headers and see if it worked or not, and try until you found the style
that worked with the given kernel version.  With the removal of the
symlinks in 2.6.29, this is no longer possible.

Now if you already knew which style to use, then you could just compile
with kbuild and be happy, but well, you don't know yet so you need to
find out somehow.

Nvidia's solution has been to use a script to do compile tests.
This doesn't work now.  Some others have used #ifdef's that check the
kernel version and rely on which kernel version changed the behaviour
and go by that.  I have now done that for the nvidia package, and it
does work for 2.6.29 and 2.6.26, but not 2.6.27 and 2.6.28.

What happened is that debian's 2.6.27 and 2.6.28 packages
apparently contained a patch that changed the syntax of the function
smp_call_function, to the 3 argument version that now appears in 2.6.29,
while the pure kernel from kernel.org only uses the 3 argument version
starting with 2.6.29, while 2.6.28 and older use the 4 argument version
of the function.

So now I can either code the #ifdef's to look for the kernel.org version
and assume 3 argument smp_call_function starts at 2.6.29, and 4 argument
is used for lower versions, or I can use the debian kernel's and say
2.6.27 and higher uses the 3 argument and 2.6.26 and lower use 4 argument.
Either way, someone is going to loose.  Debian kernel users or kernel.org
kernel users.  I can't support both.

So unless someone can tell me how to test the syntax of a function in
terms of how many arguments it takes and such, using compile time checks
(ie #ifdef's), then this simply can't work.  The only thing that did
seem to work with these kind of API changes being done to the kernel
with patches was to run compile tests against the headers, which means
the symlink tree must be restored.

So does anyone have a solution to this mess?

I highly doubt debian's kernel maintainers will promise to never ever add
a patch that changes kernel function call syntax again (as was clearly
done in 2.6.27 and 2.6.28), so some way to test is required.

-- 
Len Sorensen


Reply to: