Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262253AbUDOVu5 (ORCPT ); Thu, 15 Apr 2004 17:50:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262382AbUDOVu5 (ORCPT ); Thu, 15 Apr 2004 17:50:57 -0400 Received: from pfepa.post.tele.dk ([195.41.46.235]:5941 "EHLO pfepa.post.tele.dk") by vger.kernel.org with ESMTP id S262253AbUDOVux (ORCPT ); Thu, 15 Apr 2004 17:50:53 -0400 Date: Thu, 15 Apr 2004 23:59:07 +0200 From: Sam Ravnborg To: Axel Weiss Cc: linux-kernel@vger.kernel.org Subject: Re: compiling external modules Message-ID: <20040415215907.GD2656@mars.ravnborg.org> Mail-Followup-To: Axel Weiss , linux-kernel@vger.kernel.org References: <200404152305.49456.aweiss@informatik.hu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404152305.49456.aweiss@informatik.hu-berlin.de> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3179 Lines: 71 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 > be a basic name for the module, so .(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 , 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 _.o, > and the object-names can be collected in a symbol -obj-names. > Some objects may export symbols to other modules, they can be collected in a > -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 > - > - -obj-names > - -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/