Driver porting to Linux 2.6
The 2.6 kernel has brought along with it a pretty significant list of changes for driver developers. This section highlights some of the important aspects of device driver porting from the 2.4 to 2.6 kernel.
First, the kernel build system has been improved for quicker builds compared with 2.4. Improved graphical tools have been added: make xconfig (requires Qt libraries) and make gconfig (requiring GTK libraries).
The following are some of the highlights of the 2.6 build system:
Creates arch-zImage and modules by default when just make is issued
For parallel make, make -jN is the preferred choice
make is not verbose by default (set KBUILD_VERBOSE=1 or use make V=1 to change this)
make subdir/ will compile all the files within subdir/ and below
make help will provide the make targets supported
make dep need not be run at any stage
The kernel module loader has also been completely reimplemented in 2.5, which means that the module-building mechanism is much different compared to 2.4. A new set of module utilities is needed for module loading and unloading (please see Resources for a download link for those). Old 2.4 makefiles will no longer work as of 2.6.
The new kernel module loader is the work of Rusty Russel. It makes use of the kernel build mechanism and produces a .ko (kernel object) module object instead of an .o module object. The kernel build system compiles the module first and then links to vermagic.o. This creates a special section in the object module that contains information like the compiler version used, the kernel version, whether kernel preemption is used, and so on.
Now let's take an example and analyze how the new kernel build system should be used to compile and load a simple module. The module concerned is a "hello world" module and is similar to 2.4 module code except that module_init and module_exit need to be used instead of init_module and cleanup_module (kernel 2.4.10 modules onwards use this mechanism). The module is named hello.c and the Makefile is as follows:
This makefile uses the kernel build mechanism to build the module. The compiled module will be named module.ko and is obtained by compiling hello.c and linking with vermagic. KERNEL_SRC indicates the kernel source directory and SUBDIR indicates the directory where the module is located. EXTRA_FLAGS indicate any compile-time flags that need to be given.
Once the new module (module.ko) is created, it can be loaded and unloaded by using the new module utilities. Older module utilities used in 2.4 cannot be used for loading and unloading the 2.6 kernel modules. The new module loading utility tries to minimize the occurrence of race conditions that may occur when a device is opened while the corresponding module is being unloaded, but after the module has made sure that no one is using it. One of the reasons for these race conditions is that the module usage count is manipulated within the module code itself (via MOD_DEC/INC_USE_COUNT).
In 2.6, the module need not do this step of increasing/decreasing the reference count. Instead, this is now done outside of module code. Any code that tries to reference the module has to call try_module_get(&module), and upon success can access the module; this call will fail if the module is being unloaded. Correspondingly, references to the module can be released by using module_put().
[^] # Re: Porter un driver sur un 2.6
Posté par TheBreton . En réponse au journal Porter un driver sur un 2.6. Évalué à 1.
a la norme ton module qui viens du 2.4.xx
doc consultable en ligne a:
http://www-106.ibm.com/developerworks/linux/library/l-inside.html(...)
Driver porting to Linux 2.6
The 2.6 kernel has brought along with it a pretty significant list of changes for driver developers. This section highlights some of the important aspects of device driver porting from the 2.4 to 2.6 kernel.
First, the kernel build system has been improved for quicker builds compared with 2.4. Improved graphical tools have been added: make xconfig (requires Qt libraries) and make gconfig (requiring GTK libraries).
The following are some of the highlights of the 2.6 build system:
Creates arch-zImage and modules by default when just make is issued
For parallel make, make -jN is the preferred choice
make is not verbose by default (set KBUILD_VERBOSE=1 or use make V=1 to change this)
make subdir/ will compile all the files within subdir/ and below
make help will provide the make targets supported
make dep need not be run at any stage
The kernel module loader has also been completely reimplemented in 2.5, which means that the module-building mechanism is much different compared to 2.4. A new set of module utilities is needed for module loading and unloading (please see Resources for a download link for those). Old 2.4 makefiles will no longer work as of 2.6.
The new kernel module loader is the work of Rusty Russel. It makes use of the kernel build mechanism and produces a .ko (kernel object) module object instead of an .o module object. The kernel build system compiles the module first and then links to vermagic.o. This creates a special section in the object module that contains information like the compiler version used, the kernel version, whether kernel preemption is used, and so on.
Now let's take an example and analyze how the new kernel build system should be used to compile and load a simple module. The module concerned is a "hello world" module and is similar to 2.4 module code except that module_init and module_exit need to be used instead of init_module and cleanup_module (kernel 2.4.10 modules onwards use this mechanism). The module is named hello.c and the Makefile is as follows:
Listing 3. Example driver makefile
KERNEL_SRC = /usr/src/linux
SUBDIR = $(KERNEL_SRC)/drivers/char/hello/
all: modules
obj-m := module.o
hello-objs := hello.o
EXTRA_FLAGS += -DDEBUG=1
modules:
$(MAKE) -C $(KERNEL_SRC) SUBDIR=$(SUBDIR) modules
This makefile uses the kernel build mechanism to build the module. The compiled module will be named module.ko and is obtained by compiling hello.c and linking with vermagic. KERNEL_SRC indicates the kernel source directory and SUBDIR indicates the directory where the module is located. EXTRA_FLAGS indicate any compile-time flags that need to be given.
Once the new module (module.ko) is created, it can be loaded and unloaded by using the new module utilities. Older module utilities used in 2.4 cannot be used for loading and unloading the 2.6 kernel modules. The new module loading utility tries to minimize the occurrence of race conditions that may occur when a device is opened while the corresponding module is being unloaded, but after the module has made sure that no one is using it. One of the reasons for these race conditions is that the module usage count is manipulated within the module code itself (via MOD_DEC/INC_USE_COUNT).
In 2.6, the module need not do this step of increasing/decreasing the reference count. Instead, this is now done outside of module code. Any code that tries to reference the module has to call try_module_get(&module), and upon success can access the module; this call will fail if the module is being unloaded. Correspondingly, references to the module can be released by using module_put().