From: Axel Weiss <aweiss@informatik.hu-berlin.de>
To: linux-kernel@vger.kernel.org
Subject: compiling external modules
Date: Thu, 15 Apr 2004 23:05:49 +0200 [thread overview]
Message-ID: <200404152305.49456.aweiss@informatik.hu-berlin.de> (raw)
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.
Starting point was http://lwn.net/Articles/driver-porting/ which provides very
good and useful information. But there were some difficulties which I briefly
describe:
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.
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.
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.
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.
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.
Here is my solution:
Module-specific Makefile example: adc64-Makefile
#/***************************************************************************
# * *
# * This program is free software; you can redistribute it and/or modify *
# * it under the terms of the GNU General Public License as published by *
# * the Free Software Foundation; either version 2 of the License, or *
# * (at your option) any later version. *
# * *
# ***************************************************************************/
#
#/*
# * (C) 2004 by Axel Weiss (aweiss@informatik.hu-berlin.de)
# */
MOD_NAME := adc64
ifeq ($($(MOD_NAME)_PWD),)
export $(MOD_NAME)_PWD := $(shell pwd)
endif
$(MOD_NAME)-obj-names := device io mailbox module ringbuffer talker
#$(MOD_NAME)-exp-names := not defined (no symbols exported here)
EXTRA_CFLAGS := -I$($(MOD_NAME)_PWD)/../include \
$(if $(ADC64_DEBUG),-DADC64_DEBUG,)
include ../../Makefile.module #Path to Makefile.module
#*****************************************************************************
Makefile.module:
#/***************************************************************************
# * *
# * This program is free software; you can redistribute it and/or modify *
# * it under the terms of the GNU General Public License as published by *
# * the Free Software Foundation; either version 2 of the License, or *
# * (at your option) any later version. *
# * *
# ***************************************************************************/
#
#/*
# * (C) 2004 by Axel Weiss (aweiss@informatik.hu-berlin.de)
# */
KERNELVERSION := $(shell uname -r)
KDIR := /lib/modules/$(KERNELVERSION)/build
PWD := $(shell pwd)
KERNELBASE := $(basename $(KERNELVERSION))
KERNELMINOR := $(suffix $(KERNELBASE))
KERNELMAJOR := $(basename $(KERNELBASE))
KERNELMINOR_0_3 := $(strip $(foreach V, .0 .1 .2 .3, $(shell [ "$(V)" = \
"$(KERNELMINOR)" ] && echo yes)))
KERNELMINOR_4_5 := $(strip $(foreach V, .4 .5, $(shell [ "$(V)" = \
"$(KERNELMINOR)" ] && echo yes)))
.PHONY: all clean
ifeq ($(KERNELMAJOR),2)
ifeq ($(KERNELMINOR_0_3),yes)
all:
@echo *** kernel $(KERNELVERSION) not supported
@echo please upgrade to kernel 2.4 or newer
else # ifeq ($(KERNELMINOR_0_3),yes)
ifneq ($(KERNELRELEASE),)
obj-m = $(MOD_NAME).o
$(MOD_NAME)-objs := $($(MOD_NAME)-obj-names:%=$(MOD_NAME)_%.o)
export-objs := $($(MOD_NAME)-exp-names:%=$(MOD_NAME)_%.o)
ifeq ($(KERNELMINOR_4_5),yes)
include $(KDIR)/Rules.make
$(MOD_NAME).o: $($(MOD_NAME)-objs)
$(Q)$(LD) $(LD_RFLAG) -r -o $@ $($(MOD_NAME)-objs)
endif # ifeq ($(KERNELMINOR_4_5),yes)
else # ifneq ($(KERNELRELEASE),)
all:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
# $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
rm -f $(MOD_NAME).ko *.o .*.cmd .*.o.flags $(MOD_NAME).mod.c
$(KDIR)/.tmp_versions/$(MOD_NAME).mod
endif # ifneq ($(KERNELRELEASE),)
endif # ifeq ($(KERNELMINOR_0_3),yes)
else # ifeq ($(KERNELMAJOR),2)
all:
@echo *** kernel $(KERNELVERSION) not supported
@echo please upgrade to kernel 2.4 or newer
endif #ifeq ($(KERNELMAJOR),2)
#*****************************************************************************
Regards,
Axel
next reply other threads:[~2004-04-15 21:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-15 21:05 Axel Weiss [this message]
2004-04-15 21:59 ` Sam Ravnborg
2004-04-16 7:22 ` Duncan Sands
2004-04-16 12:06 ` Axel Weiss
2004-04-16 12:34 ` Axel Weiss
2004-04-16 16:55 ` Sam Ravnborg
2004-04-16 15:41 Axel Weiss
2004-04-16 16:54 ` Sam Ravnborg
2004-04-16 20:09 ` Axel Weiss
2004-04-16 20:51 ` Sam Ravnborg
2004-04-16 21:04 ` Sam Ravnborg
2004-04-16 23:24 ` Axel Weiss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200404152305.49456.aweiss@informatik.hu-berlin.de \
--to=aweiss@informatik.hu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®