Mailinglist Archive: opensuse-features (518 mails)

< Previous Next >
[openFATE 305148] Automatic Compiling of Kernel Modules
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 12 Aug 2010 22:30:49 +0200 (CEST)
  • Message-id: <feature-305148-28@xxxxxxxxxxxxxx>
Feature changed by: jpxviii jpxviii (jpxviii)
Feature #305148, revision 28
Title: Automatic Compiling of Kernel Modules

+ Hackweek V: Unconfirmed
+ Priority
+ Requester: Important

openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger)
reject date: 2009-06-09 15:27:03
reject reason: See comment #16.
Requester: Important

openSUSE-11.4: Unconfirmed
Requester: Mandatory

Requested by: Andreas Jaeger (a_jaeger)

The Standard Linux-Kernel provides a lot of hardware drivers/kernel
modules. Nevertheless there are still devices not supported by the
If a user compiles a kernel module by himself, he has to redo this step
after each kernel update (if he is aware at all, that this step is
needed). My idea was to install kernel-source, kernel-syms, gcc and
make with each standard installation and to define a standard directory
for the source code of kernel modules, e.g /usr/src/updates.
When a Kernel Update is done, the system looks on boot in
/usr/src/updates for directories and does there a 'make' and 'make
install'. (build a kmp-package ?)
If this could become a standard for other distributions (LSB) as well
and corresponding init scripts would exist, third party kernel modules
could be installed automagically after extracting code to
/usr/src/update, so there would be some kind of standard for installing
external kernel modules.

- bugzilla feature (url:

#2: Susanne Oberhauser (froh) (2008-08-04 19:47:06)
The linux foundation has dedicated a workgroup
( to this topic.
In this workgroup we have active Novell, RH, canonical and dell and
We have agreed to focus our energies for the distributions to
precompiled modules, as that is the only means to assert predictable
behaviour in case of kernel updates.
Without that, a recompile may (and sometimes will) fail. depending on
the module this will leave the system in a non-bootable state.
For that reason we've identified dkms as a a great tool help with the
backport and developer build of backported modules, or modules that are
on their way into mainline, still, but we've also concluded that source
distribution to end users does more harm than good to Linux
distribution users as a failing kernel update is hard to recover from.
The workgroup has agreed to develop a simple standard format to feed
driver tarballs and backport patches into dkms, and that can indeed be
used to automate the build, but we believe it should be used in
something like the build service, not on the end user system, to avoid
unexpected, hard to recover from failures after kernel updates.

#13: Martin Zboƙil (nescius) (2009-03-04 15:06:22)
Dell created a dkms tool which uses gcc to compile kernel modules from
source on boot if kernel is changed, some distributions are already
using it for both mayor proprietary GPU driver vendors.

#14: Susanne Oberhauser (froh) (2009-03-05 00:16:25) (reply to #13)
Yah. The key reason we created KMPs instead of just using dkms was that
data center customers like deutsche bank want to get rid of a compiler
on the machine, for very valid security reasons.
KMPs are enterprise class, precompiled, pretested, well-defined code.
dkms is the fancy I compile myself "fingers crossed most time it works
if not the community helps" solution.

#16: Andreas Jaeger (a_jaeger) (2009-06-09 15:26:54) (reply to #14)
I agree. If somebody implements this for openSUSE as separate package,
let's experiment with it and consider adding it to the media - but
right now I think that KMPs and the inclusion of the staging tree in
the Linux Kernel main tree solves this as well.

openSUSE Feature:

< Previous Next >
This Thread