Re: compiling external modules

From: Axel Weiss (aweiss_at_informatik.hu-berlin.de)
Date: 04/16/04

  • Next message: Christoph Hellwig: "Re: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B1" 
    To: Sam Ravnborg <sam@ravnborg.org>
Date:	Fri, 16 Apr 2004 14:06:17 +0200

    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@vger.kernel.org
    > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Christoph Hellwig: "Re: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B1"