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 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
