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.
On Sat, 06 Apr 2002 14:48:02 +1000
Keith Owens <[email protected]> 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
On Sun, 7 Apr 2002 17:36:46 +1000,
Rusty Russell <[email protected]> wrote:
>On Sat, 06 Apr 2002 14:48:02 +1000
>Keith Owens <[email protected]> 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.