Re: kbuild 2.5 problems with netfilter linking

[Rusty Russell <rusty@rustcorp.com.au>]

On Sat, 06 Apr 2002 14:48:02 +1000
Keith Owens <kaos@ocs.com.au> wrote:

> AKA - Rusty shoots himself in the foot :)
> 
> kbuild 2.5 defines
> 
>  -DKBUILD_OBJECT=module, the name of the module the object is linked
>     into, without the trailing '.o' and without any paths.  If the
>     object is a free standing module or is linked into vmlinux then the
>     "module" name is the object itself.  Automatically generated.
> 
> This variable is aimed at standardizing boot and module parameters, so
> 'insmod foo option=value' and booting with 'foo.option=value' will have
> exactly the same effect.  Rusty already has code to do this and is
> waiting for kbuild 2.5 to go in.
> 
> Alas netfilter has objects that are linked into multiple modules,
> $(ip_nf_compat-objs) is linked into both ipfwadm and ipchains so
> KBUILD_OBJECT is ambiguous.  Two possible solutions -
> 
> * Change netfilter so the objects are not linked twice.  That will
>   require $(ip_nf_compat-objs) to be a module in its own right with
>   extra exported symbols.

I considered this very carefully when I wrote the code, but the interface
exposed by it is quite ugly: it really is an internal interface between
the two.

> * Change kbuild 2.5 to detect multi linked objects and not set
>   KBUILD_OBJECT for those objects.  It follows that multi linked
>   objects cannot have module or boot parameters, so change modules.h to
>   barf on MODULE_PARM() and __setup() when KBUILD_OBJECT is not
>   defined.
> 
> I am tending towards the second solution.

You missed "#include "foo.c"" as a possible workaround.  Note that it's
a waste of disk space, not memory, since these cannot be loaded at the
same time.

Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy