Re: External kernel modules, second try
From: Sergey Vlasov
Date: Sun Mar 07 2004 - 10:13:11 EST
On Sun, 07 Mar 2004 14:32:14 +0100, Andreas Gruenbacher wrote:
> Now with mainline, when building external modules they will end up not
> having modversions. This is caused by the way .tmp_versions is handled,
> and is a real problem. There are two different ways how we are building
> external modules today:
>
> (1) after the kernel source tree was just compiled, so the kernel
> source tree still contains all the object files,
>
> (2) in a separate step, against an almost clean kernel source tree.
> Almost-clean means the tree contains a set of configuration files,
> and the modversions dump file.
>
> The modversions dump file elegantly solves both cases.
However, one little problem still remains: What if external modules from
one package need to use symbols from modules which are also external, but
in a different package? We have a similar situation in 2.4.x with lirc
modules, which reference symbols from bttv (and bttv is built in a
separate package together with some other out-of-tree v4l modules, because
they need a common tuner module).
Suggestions:
- Create a subdirectory for modversions dump files (the dump file for the
kernel will go into modversions/kernel).
- Allow multiple "-i DUMPFILE" options in modpost. Wildcard handling will
be in the Makefiles:
modver_files := $(wildcard $(srctree)/modversions/*)
modpost_input_flags := $(addprefix -i ,$(modver_files))
- Make "-o NEWDUMPFILE" work properly even after "-i DUMPFILE" (mark all
symbols which were read from a dump file and do not output such symbols
when writing the new dump file).
- Add a way to specify the output dump filename for modpost when building
external modules.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/