Driver porting: compiling external modules

I believe there was some minor controversy on the linux-kernel mailing list recently over which location is more appropriate.

Ron Arts

Even if we were building on Linux, it's unlikely that the OS on the build machine is going to match the embedded environment.

Or I am missing something?

Is there a compiler parameter to achieve global variables across multiple files of a module? It's strange, because in kernel 2.4 my module worked properly

Compiling using a standard make command and Makefile
does not understand (can not find) 'obj-m' . Is my basic way of compiling
now wrong?
obj-m:=Mydriver.o give the above error

In the 2.4 driver, I simply had a build rule that said

assembly_stuff.o: assembly_stuff.asm
nasm $(NASM_FLAGS) assembly_stuff.asm

I tried doing the same thing with the 2.6 driver and added

my_driver-objs := assembly_stuff.o

The problem is that the makefile insists that it needs a assembly_stuff.s, presumably to send through GAS.

How can I get around this?

after quite a bit of googleing i found the
solution: recompile the kernel with the running
config (the last kernel i had built was for my
gateway and used no modules, had no module
support - which might have been the problem -
although my running kernel had module support)

hope this is useful

Cheers
-Kipp

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?

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^_^

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...

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?

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

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

//#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 ?

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.

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

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.

Any help is appreciated.

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

where test.c is my module name

Please help th an answer

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!

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

or

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!