lkml.org 
[lkml]   [2004]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: compiling external modules
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.085 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site