LWN: Comments on "Driver porting: compiling external modules"

Testing the usb-skeleton.c

saurabh8189 — Mon, 26 Apr 2010 12:54:21 +0000

Thanks for the article I have been following your book for a long time. I am working on usb-skeleton.c driver for the pen(say usb flash drive :)) drive on kernel 2.6.32.
I am able to load usb-skeleton module to kernel using insmod but every time I plug-in my pen drive it takes usb-storage module.
Due to this I am not able to test my first driver.
I asked various forums but got no results now you are the one who guided and can guide
Here is a link to my question
http://www.linuxforums.org/forum/linux-kernel/161862-how-...

Waiting for the reply!!

Driver porting: compiling external modules

ffo — Fri, 13 Apr 2007 22:04:31 +0000

The information is misleading as far as I can judge by the number of posts. Here is my contribution.

If your module is made of f1.c f2.c and f3.c then your Makefile should look like:
obj-m:= module.o
module-objs := f1.o f2.o f3.o

you will be able to load your module by insmod ./module.ko.
Note that module.o is NOT associated to any .c, it is just the product name of the compilation.

Now to take other names, misleading ones...
If your module is made of interceptor.c frame.c and packet.c then your Makefile should look like:
obj-m:= module.o
module-objs := interceptor.o frame.o packet.o
or
obj-m:= interceptor_module.o
interceptor_module-objs := interceptor.o frame.o packet.o

if your Makefile is
obj-m:= interceptor.o
interceptpr-objs := interceptor.o frame.o packet.o

it will report a circular depdendency and not compile interceptor.c

obj-m:= interceptor.o
interceptor-objs := frame.o packet.o

it will NOT compile interceptor.c, produce an interceptor.ko (bad), emit some warnings about undefined references. Trying to load it by insmod will produce errors about unresolved stuff.

Again, the name after obj-m does NOT correspond to any .c but to the name of the .ko you want to obtain from make. The fact that it is named with a .o extension is very misleading... it should have been .ko IHMO.

This may sound obvious for the kernel development community, but for newbies like me, this is way different!

How to compile an external driver using a non-default makefile name?

Linux_v — Tue, 09 Jan 2007 00:27:02 +0000

Hi,

I used to be able to compile an external device driver using the command in 2.4 kernel:

make -f mymakefile

But in 2.6 kernel, the command doesn't work.

1) With this command
$(MAKE) -C $(KDIR) M=$(PWD) modules

I saw the following error:

[root@pgenlx11 platypus]# make -f mymakefile
make -C /lib/modules/2.6.11.1/build M=/my-correct-ldd-dir modules
make[1]: Entering directory `/usr/src/kernels/linux-2.6.11.1'
scripts/Makefile.build:13: /my-correct-ldd-dir/Makefile: No such file or directory
make[2]: *** No rule to make target `/my-correct-ldd-dir/Makefile'. Stop.
make[1]: *** [_module_/my-correct-ldd-dir] Error 2
make[1]: Leaving directory `/usr/src/kernels/linux-2.6.11.1'
make: *** [all] Error 2

From reading the porting article, I've learnt that the 2.6 kernel build process goes through two passes for building an external device driver. The second pass is where it does the building job. But it looks like it was looking for a default makefile, named Makefile, even though, "-f mymakefile" is given at the make command.

2) with this command
$(MAKE) -C $(KDIR) M=$(PWD) -f mymakefile modules

I saw this the following error: basically, the build process try to look for mymakefile in the linux source tree, instead of the the dir defined by M=$(PWD).

[root@pgenlx11 platypus]# make -f mymakefile
make -C /lib/modules/2.6.11.1/build M=/my-correct-ldd-path modules -f mymakefile
make[1]: Entering directory `/usr/src/kernels/linux-2.6.11.1'
make[1]: mymakefile: No such file or directory
make[1]: *** No rule to make target `mymakefile'. Stop.
make[1]: Leaving directory `/usr/src/kernels/linux-2.6.11.1'
make: *** [all] Error 2

3) case 1, "make -f mymakefile", will work fine if I add the following symbolic link:
ln -s mymakefile Makefile

I tried this just to test if there is other problem for the make. It's not a solution for me.

I saw the linux build script uses "make -f " in some case. it look like it should work in 2.6 as well. What have I missed?

Thanks in advance!

What about cross-compilation?

DeferX — Tue, 02 May 2006 13:59:20 +0000

Tray this
make CROSS_COMPILE=ppc_6xx- ARCH=ppc
It's work

By
defer

Driver porting: loading external modules

nusrath — Thu, 15 Dec 2005 06:41:04 +0000

When i load the module using insmod the following error is hown

insmod: can't read 'test.ko': Stale NFS file handle

where test.c is my module name

Please help th an answer

What about cross-compilation?

urs — Thu, 10 Nov 2005 22:02:46 +0000

You should call

make CROSS_COMPILE=ppc_4xx- -C ...

instead of your command

CROSS_COMPILE=ppc_4xx- make -C ...

which handles make variables differently. See the make manual for details.

urs

What about cross-compilation?

msprauve — Fri, 14 Oct 2005 00:02:03 +0000

Did anyone develop a resolution to this problem?

Driver porting: compiling external modules

mraviraj — Wed, 14 Sep 2005 23:45:18 +0000

We have been using linux 2.4 for the development and recently started supporting 2.6.

I need to port our existing makefiles to work with 2.4 and 2.6.

while i am trying to use following syntax for 2.4, it is just doing 'make clean' job in linux kernel directory.

ifeq ($(KERNELRELEASE),)
obj-m := foo.o
else
KDIR := /linux/kernel/src/v2.4/linux-2.4.31
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif

foo-objs := foo1.o foo2.o

Can someone please share their experience in compiling the same source code for 2.4 and 2.6 ?

thanks ..
Raviraj

problem with $(CURDIR)

qu1j0t3 — Sun, 31 Jul 2005 20:42:19 +0000

The GNU make docs say that $(CURDIR), when used with -C, will be the 'new' directory, not the module directory, which would make it incorrect in this situation anyway... I think :-)

Hardware vendor supplied modules

qu1j0t3 — Fri, 22 Jul 2005 16:55:25 +0000

IT'S YOUR IMAGINATION

unable to use ksyms on 2.6 kernel

kalou — Mon, 18 Jul 2005 11:38:09 +0000

Hi rashminivarthy,

your kernel is not module enabled,
obviously.

Sincere Regards,

Olivier

Unable to compile external modules in 2.6-9.5 kernel

muraligadela — Wed, 30 Mar 2005 19:31:20 +0000

Hi
I am porting simple device driver from 2.4 kernel to 2.6.9-5. I followed the instructions in the "compiling external modules" articles posted in the lwn.net. I am still unable to compile and the compiler errror received is
awk: cmd. line:2 fatal: cannot open file `test.h` for reading (no such file or directory). I have added the location of test.h to CFLAGS varaible and also to EXTRA_CFLAGS in the makefile.

Any help is appreciated.

Driver porting: compiling external modules

krash — Tue, 22 Mar 2005 17:40:49 +0000

To save the uninitiated from pulling too much hair out:

In the example:

obj-m := module.o
module-objs := file1.o file2.o

It might be clearer for it to read something like this:

obj-m := name-of-module.o
name-of-module-objs := file1.o file2.o

to stress that in the original module-objs, module is in fact the name of the module.

What about cross-compilation?

mhb — Thu, 03 Mar 2005 10:48:11 +0000

I have tried this on the simple hello.c module.
I use the ELDK cross compiler to generate code for
a ppc 440 from an X86 based machine. It fails
with some emulation mode problems, any ideas ?

[root@basher ebonymnt]# export CROSS_COMPILE=ppc_4xx-
[root@basher ebonymnt]# make -C /home/simon/ebonymnt/linux-2.6.10 M=`pwd`
make: Entering directory `/home/simon/ebonymnt/linux-2.6.10'
LD /home/simon/ebonymnt/built-in.o
CC [M] /home/simon/ebonymnt/hello.o
Building modules, stage 2.
MODPOST
CC /home/simon/ebonymnt/hello.mod.o
LD [M] /home/simon/ebonymnt/hello.ko
ppc_4xx-ld: unrecognised emulation mode: elf_i386
Supported emulations: elf32ppclinux elf32ppc elf32ppcsim
make[1]: *** [/home/simon/ebonymnt/hello.ko] Error 1
make: *** [modules] Error 2
make: Leaving directory `/home/simon/ebonymnt/linux-2.6.10'
[root@basher ebonymnt]#

Driver porting: compiling external modules

fleetinglife — Fri, 04 Feb 2005 06:51:54 +0000

I built my driver successfully in kernel 2.6.0,
BUT when I insmod the .ko file, I got
"no module found in object
Error inserting 'name.ko' : -1 Invalid module format"

Who can tell me, where can I get docs about module format in kernel 2.6.0?

Driver porting: compiling external modules

fleetinglife — Thu, 03 Feb 2005 09:30:40 +0000

I see, The module-objs should be modified into file_mod-objs.

Driver porting: compiling external modules

fleetinglife — Thu, 03 Feb 2005 03:28:22 +0000

I am struggling to build my first linux driver module.

I have four .c files in my source directroy, the file file_mod.c is the one contains the main code of module. I use the Makefile as following:

obj-m := file_mod.o
module-objs := file1.o file2.o file3.o file_mod.o

and type make command as following:

make -C /usr/src/linux-2.6.0 SUBDIRS=$PWD modules

It can build the file_mod.ko successfully, but I got a list of warning messages, said some functions called in file_mod.ko UNDEFINED! These functions are defined in file1.c, file2.c, file3.c.

How to solve this problem? Any suggestion will be appreciated.

Driver porting: compiling external modules

meenaxi — Thu, 09 Dec 2004 14:25:19 +0000

hello,

First I would like to say Thanks for this article, it was very helpful!!
but unfortunately I am still facing some problems.

I am running Suse-9.1 Linux kernel and I want to write a loadable module.
I tried the helloworld program and it is working just fine, but then i
started with a simple character device driver program which is given as
example in Linux Module programming guide-2.6. but when i run the make
for this the whole make is running without error(there are a few
warnings) but the chardev.ko or chardev.o is not formed. i have no idea
why???.....any help would be appreciated!!

Thanks a dozen
meenaxi.

Driver porting: compiling external modules

wuyanmin2 — Fri, 26 Nov 2004 09:44:13 +0000

My kernel version is 2.6.5, I complied a "Hello world" module,it's very simple but the size is more than 100K, however, most of the kernel modules in /lib/modules/ are less than 50K . What's the matter? How can I complie a smaller module??

Thanks

WU Yan-min

Driver porting: compiling external modules

kabbalah — Tue, 09 Nov 2004 21:25:06 +0000

thank you for your reply, I tried your code but when i compile it I still get plenty of errors:
cc hello.c -o hello
In file included from /usr/include/linux/sched.h:12,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/jiffies.h:16: error: parse error before "jiffies_64"
/usr/include/linux/jiffies.h:20: error: parse error before "get_jiffies_64"
In file included from /usr/include/linux/sched.h:21,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/asm/mmu.h:13: error: field `sem' has incomplete type
In file included from /usr/include/linux/signal.h:4,
from /usr/include/linux/sched.h:25,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/list.h:604:2: warning: #warning "don't include kernel headers in userspace"
In file included from /usr/include/asm/siginfo.h:4,
from /usr/include/linux/signal.h:7,
from /usr/include/linux/sched.h:25,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/asm-generic/siginfo.h:53: error: size of array `_pad' is too large
In file included from /usr/include/linux/sched.h:27,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/fs_struct.h:9: error: parse error before "rwlock_t"
/usr/include/linux/fs_struct.h:13: error: parse error before '}' token
In file included from /usr/include/linux/sched.h:29,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/completion.h:15: error: parse error before "wait_queue_head_t"
/usr/include/linux/completion.h: In function `init_completion':
/usr/include/linux/completion.h:26: error: dereferencing pointer to incomplete type
/usr/include/linux/completion.h:27: error: dereferencing pointer to incomplete type
In file included from /usr/include/linux/sched.h:30,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/pid.h: At top level:
/usr/include/linux/pid.h:18: error: field `task_list' has incomplete type
/usr/include/linux/pid.h:19: error: field `hash_chain' has incomplete type
/usr/include/linux/pid.h:24: error: field `pid_chain' has incomplete type
In file included from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/sched.h:93: error: parse error before "process_counts"
In file included from /usr/include/linux/sched.h:102,
from /usr/include/linux/module.h:9,
from hello.c:2:
/usr/include/linux/timer.h:10: error: field `entry' has incomplete type
hello.c:22: error: parse error before "__attribute_used__"
hello.c:22: warning: initialization makes integer from pointer without a cast
hello.c:22: warning: data definition has no type or storage class
hello.c:23: error: parse error before "__attribute_used__"
hello.c:23: error: redefinition of `__attribute_used__'
hello.c:22: error: `__attribute_used__' previously defined here
hello.c:23: warning: initialization makes integer from pointer without a cast
hello.c:23: warning: data definition has no type or storage class
hello.c:23:25: warning: no newline at end of file
make: *** [hello] Error 1

when i remove the #include <linux/modules.h> directive I get less errors but it still won't compile:
cc hello.c -o hello
hello.c:6: error: parse error before string constant
hello.c:6: warning: data definition has no type or storage class
hello.c:22: error: parse error before "__attribute_used__"
hello.c:22: warning: initialization makes integer from pointer without a cast
hello.c:22: warning: data definition has no type or storage class
hello.c:23: error: parse error before "__attribute_used__"
hello.c:23: error: redefinition of `__attribute_used__'
hello.c:22: error: `__attribute_used__' previously defined here
hello.c:23: warning: initialization makes integer from pointer without a cast
hello.c:23: warning: data definition has no type or storage class
make: *** [hello] Error 1

so that makes me pretty much desperate now :)
I guess I will have to forget about LKMs till the next Linux I install...
anyhow 10x again :)

Driver porting: compiling external modules

madhavi_srinivas — Tue, 09 Nov 2004 10:16:12 +0000

Dear Kabbalah,

I am using SuSE 9.1 with 2.6.5-7.71 kernel. I have written small hello.c program here. It was working fine on my x86 machine.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");

static int hello_init(void)
{
printk("Hello World!\n");
return 0;
}

static void hello_exit(void)
{
printk("Good bye!\n");
}

module_init(hello_init);
module_exit(hello_exit);

For this the make file is as follows.

KDIR:=/lib/modules/$(shell uname -r)/build

obj-m:=hello.o

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
$(RM) .*.cmd *.o *.ko -r .tmp*

It was working fine under x86 machine with 2.6.5-7.71 kernel version with SuSE Linux.

Regards,
Srinivas G

Driver porting: compiling external modules

kabbalah — Tue, 09 Nov 2004 00:57:44 +0000

hi there
I installed SuSe 9.1 with 2.6.4-52-default kernel and I'm having some problems writing modules for it.
I've read these articles and still can't find the answer....
that's my module

//#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

//MODULE_LICENSE("Dual BSD/GPL");

static int module_init(void)
{
printk("<1>Hello world 1.\n");
return 0;
}

static void module_exit(void)
{
printk("Goodbye world 1.\n");
}

and that's the makefile

ifneq ($(KERNELRELEASE),)
obj-m:= h.o

else
KDIR:= /lib/modules/$(shell uname -r)/build
PWD:= $(shell pwd)

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif

When I compile it I get these
h.c:10: error: parse error before "__initcall_void"
h.c:10: error: parse error before "void"
h.c:19: error: parse error before "__exitcall_void"
h.c:19: error: redefinition of `__attribute_used__'
h.c:10: error: `__attribute_used__' previously defined here
h.c:19: error: parse error before "void"
make: *** [h] Error 1

any ideas why this happens ?

unable to use ksyms on 2.6 kernel

rashminivarthy — Wed, 27 Oct 2004 10:17:48 +0000

hello
i tried using ksyms on 2.6 kernel to view all the exported kernel
symbols .It gave an error-
ksyms: QM_MODULES: Function not implemented

plz any 1 reply back

Path to the kernel source

rashminivarthy — Wed, 27 Oct 2004 08:25:44 +0000

hello,
i was trying to compile a simple helloworld module on linux-2.6
kernel (Fedoracore-2)i'm geting this error while using this
makefile
---------------
|MakeFile |
----------------
ifneq ($(KERNELRELEASE),)
obj-m := hello.o
else
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif
---------------
|ERROR MESSAGE|
----------------
cc hello.c -o hello
hello.c:1:26: linux/module.h: No such file or directory
hello.c:2:27: linux/kernel.h: No such file or directory
hello.c:3:24: linux/init.h: No such file or directory
make: *** [hello] Error 1

Driver porting: compiling external modules with local includes

amcrae — Wed, 20 Oct 2004 05:24:25 +0000

What I'd like to be able to do is set a couple of extra 'include' paths. (I note from earlier articles that setting 'CFLAGS' is .. umm.. discouraged.)

I needed to do the same thing. You can do this with the EXTRA_CFLAGS Makefile variable:

...
obj-m += file.o
EXTRA_CFLAGS += -I$(obj)/../include

Cheers,
AMc

Driver porting: compiling external modules with local includes

geoff_o — Fri, 15 Oct 2004 16:48:34 +0000

I've also been searching for the answer to this question.

What I'd like to be able to do is set a couple of extra 'include' paths. (I note from earlier articles that setting 'CFLAGS' is .. umm.. discouraged.)

I hope there's a work around, otherwise it makes it difficult to develop modules outside the kernel tree that depend on each other.

Does there exist a solution?

Thanks,

Geoff

Driver porting: compiling external modules

klaus.hitschler@gmx.de — Thu, 02 Sep 2004 20:30:59 +0000

I've ported my CAN driver to Kernel 2.6.5 and I'm using the M=$(PWD) switch for making this external module. Now I got this output:

make -C /usr/src/linux M=/home/klaus/work/peak/peak-linux-driver/driver V=0 modules
make[1]: Entering directory `/usr/src/linux-2.6.5-7.108'
CC [M] /home/klaus/work/peak/peak-linux-driver/driver/src/pcan_main.o
.... a lot more ...
CC [M] /home/klaus/work/peak/peak-linux-driver/driver/src/pcan_usb.o
LD [M] /home/klaus/work/peak/peak-linux-driver/driver/pcan.o
Building modules, stage 2.
MODPOST
Warning: could not find versions for .tmp_versions/pcan.mod
CC /home/klaus/work/peak/peak-linux-driver/driver/pcan.mod.o
LD [M] /home/klaus/work/peak/peak-linux-driver/driver/pcan.ko
make[1]: Leaving directory `/usr/src/linux-2.6.5-7.108'

I wondered about the line
"Warning: could not find versions for .tmp_versions/pcan.mod".
Some investigation shows that in my $(PWD) a directory .tmp_versions was created and the pcan.mod was stored in that directory. For any strange reason a part of modpost "sumversions.c" is looking for .tmp_versions/pcan.mod located at the base of the kernel source tree. The same happens with the SUBDIRS=$(PWD) syntax.

Does anyone have an idea what' wrong?

P.S. pcan.ko is generated and is works perfectly.

Klaus

SUBDIRS= vs M=

r2b2lewis — Thu, 26 Aug 2004 17:10:25 +0000

I am running on SuSE 9.1 (2.6.4-52-smp).

When I ran the make file using the line:

$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

the make ran quickly without error.

However, when I changed that line to:

$(MAKE) -C $(KDIR) M=$(PWD) modules

I seem to be making the entire kernel again.

What's up with that?

Driver porting: compiling external modules

cidis — Tue, 24 Aug 2004 18:05:40 +0000

I'm porting driver for Pent@value card, but I dont have all sources. Some modules are already compiled. Can I link all together? How?

Driver porting: compiling external modules with local includes

cpp9999 — Mon, 09 Aug 2004 21:22:42 +0000

I'm having trouble compiling an external module under the following dir structure
A local header file sits in a directory other than the one that contains the main file
See below:
home_dir/dirA/local.h
home_dir/dirB/main.c

sample main.c file
#include "dirA/local.h"
main ()
{
/* some code */
}

# make -C /usr/src/linux-2.6.7 SUBDIRS=$(PWD) modules
When I try to compile I get the following error messages
Entering directory /usr/src/linux-2.6.7
CC [M] /home_dir/dirB/main.c:15:32: dirA/local.h: No such file or directory

Obviously when I am in /usr/src/linux-2.6.7 I cannot see local.h.

Any ideas how to fix this? Thanks

Driver porting: compiling external modules

anikami1 — Mon, 26 Jul 2004 17:37:15 +0000

I have the following problem with a device driver. It will load in my machine, but if I try to load it under a different kernel version, or on another machine with a different kernel version, I get "invalid module format" errors. I am pretty sure this has to do with the "version magic" feature of the 2.6.X kernels.

My question is, do I need to compile the module/driver under EACH kernel version out there? Is there a way to compile the module so that it loads on any machine with a 2.6.X kernel?

Multi-file modules--help!

amishdave — Sun, 25 Jul 2004 17:09:22 +0000

I think you need to replace module-objs with foo-objs...

Driver porting: compiling external modules

Ryu_Tenchi — Fri, 23 Jul 2004 23:54:14 +0000

*^^* thank you, i feel stupid now lol, but it works and I learned from it
so,thanks again^_^

Multi-file modules--help!

ajnicholson — Fri, 23 Jul 2004 19:04:07 +0000

I have an external module comprised of 3 .c files...

I made the following Makefile:
----------------------------------
obj-m := foo.o
module-objs := file1.c file2.c file3.c
-----------------------------------

yet when I compile it by running:
make -C /usr/src/linux SUBDIRS=$PWD modules

It issues the following error:
make[2]: *** No rule to make target '/usr/src/foo.c', needed by '/usr/src/foo/foo.o'. Stop.

Any ideas? I thought the "module-objs" line was supposed to indicate which files comprise the complete module...

Driver porting: compiling external modules

disq — Thu, 22 Jul 2004 15:00:00 +0000

apparently it's "obj-m", not "objs-m"

Driver porting: compiling external modules

Ryu_Tenchi — Thu, 15 Jul 2004 06:12:05 +0000

i'm a little lose so sorry for this, but i'm trying to figure this stuff out but it never actually make the module...
code:
//main.c
#include <linux/module.h>
#include <linux/config.h>
#include <linux/init.h>

int init_module(void){printk("<1>Hello, world\n"); return 0;}
void cleanup_module(void) {printk("<1>Goodbye cruel world\n");}

makefile:
objs-m := main.o

command entered:
make -C /usr/src/linux M=`pwd` modules

output:
make: Entering directory `/usr/src/linux-2.6.7-gentoo-r11'
Building modules, stage 2.
MODPOST
make: Leaving directory `/usr/src/linux-2.6.7-gentoo-r11'

any help would be great, thanks^_^

SUBDIRS= vs M=

corbet — Mon, 12 Jul 2004 13:54:38 +0000

You found the current way of doing things; the article is mildly out of date. I'll fix it, but, since the old scheme continues to work, it's not been my top priority...

SUBDIRS= vs M=

kcannon — Mon, 12 Jul 2004 02:26:41 +0000

The 2.6.7 Makefiles say that an external module should be compiled by setting the variable M to the directory in which the module resides, rather than by setting SUBDIRS. The command line is

$ make -C /path/to/kernel/source M=/path/to/your/module modules

I've confirmed that this does work. What is the reason for choosing one over the other? Are they synonyms?

Driver porting: compiling external modules

kcannon — Mon, 12 Jul 2004 02:20:27 +0000

Never mind... my mistake. You replace the default value of PWD with the result of $(shell pwd).

Driver porting: compiling external modules

kcannon — Sun, 11 Jul 2004 06:23:23 +0000

It's probably better to use $(CURDIR) in the Makefile rather than $(PWD). $(PWD) is set to the directory from which the original make command was issued, while $(CURDIR) is set to the current working directory (eg. as modified by recursive use of make -C). If the driver modules are distributed in a subdirectory of a larger software package, and the user is intended to issue a make command from the top-level directory, using $(PWD) in the driver Makefile will pick up the wrong path.

Cheers
-Kipp