Re: External kernel modules, second try

[Sergey Vlasov <vsu@altlinux.ru>]

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.