Re: compiling external modules

[Axel Weiss]

Hi, Sam,

I have patched to 2.6.6-rc1 (patch-2.6.6-rc1 over kernel 2.6.5 - am I right or 
am I missing some patches in between?), and now symbol exports between 
modules fails. An example with two module-objects - one exports some symbols 
used by the other - shows compile output:

scripts/Makefile.build:36: kbuild: /home/axel/freeSP-1.0.4/drivers/linux/
adc64/busmaster/Makefile - Usage of export-objs is obsolete in 2.6. Please 
fix!

8<

*** Warning: "adc64_count" [/home/axel/freeSP-1.0.4/drivers/linux/adc64/
driver/adc64.ko] undefined!
*** Warning: "release_adc64_busmaster" [/home/axel/freeSP-1.0.4/drivers/linux/
adc64/driver/adc64.ko] undefined!
*** Warning: "get_adc64_busmaster" [/home/axel/freeSP-1.0.4/drivers/linux/
adc64/driver/adc64.ko] undefined!

8<

The first (exporting) module loads cleanly (lsmod shows the loaded module), 
but insmod'ing the second fails with:

insmod: error inserting './adc64.ko': -1 Unknown symbol in module

What's the trick in 2.6.6?

Regards,
Axel

On Thursday 15 April 2004 23:59, Sam Ravnborg wrote:
> On Thu, Apr 15, 2004 at 11:05:49PM +0200, Axel Weiss wrote:
> > Hi,
> >
> > after some study of kernel Makefiles, I'm able now to compile externel
> > modules for both, 2.4 and 2.6 kernels correctly. I'd like to share my
> > Makefiles here, maybe somebody finds them useful.
>
> Thanks.
>
> > 2.6-compilation of drivers consisting of more than one module leaded to
> > very ugly warnings from scripts/Makefile.modpost, when make was invoked
> > after 'make clean'. The reason were lying-around objects in .tmp_versions
> > directory which were not deleted by 'make clean'. Solution: clean must
> > explicitly delete the version-object in .tmp_versions.
>
> With 2.6.5-rc1 the warning are gone.
>
> > 2.4-compilation requires inclusion of Rules.make and an additional rule
> > for module-object linkage. In 2.6 Rules.make does not exist, and the
> > linking rule would conflict with an already defined one. Solution:
> > distinct current kernel version.
>
> You should be able to use:
> -include Rules.make
>
> See 'info make' - look after the include directive.
>
> > When I gave the rule:
> > clean:
> > 	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
> > the whole kernel tree was cleaned. This is not my intention, when I'm
> > working on external modules and want to make clean e.g. for cvs commits.
> > So I defined my own clean rule, kicking away everything but source files.
>
> With 2.6.5-rc1 this will only cause files in the $(PWD) dir to be deleted,
> not the kernel tree.
>
> > So far the difficulties. Next I propose an assumption about filenames,
> > when a module consists of several objects which will be linked together.
> > Let <module-name> be a basic name for the module, so <module-name>.(k)o
> > (with k for 2.6, without for 2.4) will be the final target. I assume that
> > all elementary object-filenames begin with <module-name>, for
> > clarification. E.g. the module adc64.ko is composed of adc64_module.o,
> > adc64_device.o, adc64_io.o and so on. Generally, the name of an object is
> > <module-name>_<object-name>.o, and the object-names can be collected in a
> > symbol <module-name>-obj-names. Some objects may export symbols to other
> > modules, they can be collected in a <module-name>-exp-names list.
>
> I really do not see the benefit compared to the current more free
> naming scheme - which works.
>
> > Finally, all the modules' Makefiles were very similar, so I split them
> > into two files: one Makefile for every module and a common
> > Makefile.module which is included by each Makefile. Each module-specific
> > Makefile contains the definition of
> > - <module-name>
> > - <module-name>-obj-names
> > - <module-name>-exp-names
> > - EXTRA_CFLAGS
> > which makes up all information Makfile.module needs.
>
> The general feedback is that it looks like you have
> made it less simple than it ought to be.
>
> You should also consider that you end up with files
> that does not look like ordinary kbuild makefiles.
>
> When I get some spare time I will try to come up with a simpler example.
>
> 	Sam
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/