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

Bug#294186: Kernel Version Specific scripts/ is required

Package: kernel-headers-2.6.10-1
Version: 2.6.10-4
Severity: normal
Tags: sid experimental

On Sat, Feb 05, 2005 at 09:04:42AM +1100, Andrew Pollock wrote:
> Hi,
> As I documented in my blog[1], I struck some problems building the latest
> ipw2200 module against the kernel headers provided with 2.6.10. I also
> couldn't rebuild older versions (that had successfully built in the past).
> Is this a problem with the kernel headers or with the ipw2200 module? (I'm
> inclined to think the former, given that old stuff no longer builds, but I'm
> no kernel guru).
> [1] http://blog.andrew.net.au/2005/02/01#ipw_building_problems

Hi Andrew,

This is indeed a problem. I am creating a bug for it whith
this email (I hope). Here is my analysis of the problem.

Modules use code in scripts/modules in the kernel tree to
help build the modules. This is the code which adds the reference
to cleanup_module and init_module. Which your build is complaining

In the past if a module did not define these symbols, as the ipw2200
module does not, then dummy symbols were draged in from kernel/module.c.
However, some time in the not to distant past this was changed, so
that if the symbols were not defined, then instead of setting the
relevant pointers to the dummy symbols, the pointers are set to NULL.
The code in scripts/modules was updated accordingly.

So far so good.

Unfortunately, on inspecting the relevant kernel headers package we see

# ls -l /usr/src/kernel-headers-2.6.10-1-686/scripts
...scripts -> ../kernel-headers-2.6.10-1/scripts/
# ls -l /usr/src/kernel-headers-2.6.10-1/scripts
...scripts -> ../kernel-kbuild-2.6-3/scripts/

Uh ohh! 
Big Problem!

kernel-kbuild-2.6-3 is a common package for kernel-header packages for
all 2.6 kernels. But we know there was an incompatible change somewhere
between 2.6.8 and 2.6.10.


Ok, so what to do about it. 

I suggest moving the scripts directory into kernel-headers-2.6.10-1 and
keeping it there for subsequent 2.6. kernel headers. As far as I can
tell the only real reasons for breaking it out kernel-kbuild are to
reduce some bloat (1.7 Mbytes) and avoid a depenancy on libc. In the
case of the bloat, well these file's aren't compatible between kernel
versions, so they need to be separate. In terms of avoiding the libc
dependancy, well the package depends on kernel-kbuild-2.6-3 anyway, so
you have an indirect dependancy anyway.

I would not advocate making this change for kernel-headers-2.6.8 as
that is in sarge, and we are tying hard not to change that, and
kernel-kbuild woks for that. 2.6.10 on the other hand is not
in sarge, so lets fix that. 2.6.9 is dead, so lets leave it alone.
But we can make the change for 2.6.10 and fix it, while leaving 
2.6.8 unscathed and still working. Hooray!

As a work around try defining the dummy
symbols in your module's .c files somewhere. Here is what they used
to look like.

void cleanup_module(void)

int init_module(void)
        return 0;


Reply to: