A number of packages are provided both by SUSE and by third parties in the form of kernel module packages (KMPs).

A major problem for Linux adoption has been the fact that some third-party software requires a special kernel module to run. When the third-party vendor has been willing to "do the right thing'' and make the source for the necessary kernel module available under the GPL, this is not a problem. Linux distributors can include the source and the built binary modules in their kernel packages.

But when vendors want to avoid releasing the code under the GPL, it is a major problem for users. When the kernel changes, it is more than possible that a module available only in binary form fails to load. This is a serious problem in any case, but fatal in the case of a module needed for disk or filesystem access. It could mean that when there is a security update to the kernel, everything depending on the proprietary modules stops working.

To help to solve this problem, Novell has done two things. Steps have been taken to ensure that in the enterprise versions of Linux the binary interfaces of the kernel are changed only when absolutely necessary. At the same time, the vendors have been given the opportunity to join what is called the Partner Linux Driver Process. This allows third-party vendors to work together with Novell to ensure that when the SLES kernel changes, any update to the kernel triggers an update to the third-party driver, if it becomes necessary because of changes in the kernel's binary interfaces.

This is achieved by allowing partner FTP sites to be set up as installation sources and, at the same time, collaborating with partners on the building of new modules against the new kernel source as, and when, necessary. Logic in the update process ensures that if new versions of binary modules are required, a new kernel cannot be installed unless these are available.

An example of this arrangement is the setup of ATI and NVIDIA's video drivers in SLED. These are made available as KMPs, and the vendor sites are set up as installation sources, so the drivers can be updated if necessary. In the case of SLES, various drivers for proprietary storage devices and filesystems are made available as KMPs.

For convenience, Novell ships quite a number of kernel modules as KMPs even when the source is available; particularly, for wireless cards, soft modems, and similar hardware.

Unfortunately, not all third-party vendors who ship proprietary kernel modules have embraced this model. But it is beginning to make a difference. At the same time, the resistance to open sourcing code on the part of third-party vendors is beginning to break down. AMD's recent decision to release to the community the full specifications of the ATI graphics cards is a case in point.

In the cases where drivers are provided in binary-only form, these are said to taint the kernel when they are loaded.

SLED is discussed further in Chapter 30.

Tainting the Kernel

When certain third-party modules load, you will see a message of the form:

Warning: loading <module file> will taint the kernel: non-GPL license -Proprietary. [...]

See <> for information about tainted modules

Module <module file> loaded, with warnings

This indicates that a module with a non-GPL license is being loaded into the kernel. This warning is not simply about software ideology: When proprietary (and particularly, binary-only) modules are loaded, little can be done to debug any problems they may cause. In particular, debugging a kernel crash dump may be impossible if the source to all the loaded modules is not available.

Kernel of the Day

The SUSE FTP server always has a so-called kernel of the day, which is the latest test kernel, with versions available for each supported architecture. This is available at It goes without saying that these kernels should be used only with caution because they have not been officially released and are provided for testing purposes.

Loading Kernel Modules

In the 2.6 kernel, kernel modules have filenames ending with .ko (rather than .o as in 2.4). To check what modules are loaded, do the following:

[email protected]: ~ #




Used by









1 vfat










nls utf8




Dependencies between modules are indicated in the last column of the output. To load a module manually, you use the following: [email protected]: ~ # modprobe tulip

To unload a module, use the following:

[email protected]: ~ # rmmod tulip

The automatic loading of modules is now (in 2.6 kernels) controlled by the file /etc/modprobe .conf, which has replaced the /etc/modules.conf file.

The file /lib/modules/<version-number>-default/modules.dep contains a listing of all the dependencies between available modules. This file can be regenerated if necessary by the command depmod -a.

Was this article helpful?

0 0

Post a comment