kbuild 2.5 problems with netfilter linking

kbuild 2.5 problems with netfilter linking

[Keith Owens]

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.

* 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.

Re: kbuild 2.5 problems with netfilter linking

[Rusty Russell]

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

Re: kbuild 2.5 problems with netfilter linking

[Keith Owens]

On Sun, 7 Apr 2002 17:36:46 +1000, 
Rusty Russell <rusty@rustcorp.com.au> wrote:
>On Sat, 06 Apr 2002 14:48:02 +1000
>Keith Owens <kaos@ocs.com.au> wrote:
>> * 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.

I have implemented the second solution.  Multi linked objects get no
value for KBUILD_OBJECT.  I had to do this anyway, depending on which
order the objects were compiled, kbuild was registering different
values for KBUILD_OBJECT.  That was causing spurious rebuilds and the
command appeared to change.