Mailinglist Archive: opensuse-features (542 mails)

< Previous Next >
[openFATE 305148] Automatic Compiling of Kernel Modules
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 2 Dec 2010 15:35:20 +0100 (CET)
  • Message-id: <feature-305148-40@xxxxxxxxxxxxxx>
Feature changed by: Andreas Jaeger (a_jaeger)
Feature #305148, revision 40
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.
Priority
Requester: Important

- openSUSE-11.4: Unconfirmed
+ openSUSE-11.4: Duplicate of #308323
Priority
Requester: Mandatory

Requested by: Andreas Jaeger (a_jaeger)
Project Manager: Andreas Gruenbacher (agruen)
Technical Contact: (Novell)
Technical Contact: (Novell)
Technical Contact: Andreas Gruenbacher (agruen)
Partner organization: openSUSE.org

Description:
The Standard Linux-Kernel provides a lot of hardware drivers/kernel
modules. Nevertheless there are still devices not supported by the
kernel.
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.

Relations:
- bugzilla feature (url:
https://bugzilla.novell.com/show_bug.cgi?id=410396)
+ - (feature/duplicate: 308323)

Discussion:
#2: Susanne Oberhauser (froh) (2008-08-04 19:47:06)
The linux foundation has dedicated a workgroup
(http://www.linuxfoundation.org/en/Driver_Backport) to this topic.
In this workgroup we have active Novell, RH, canonical and dell and
IBM.
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.

#21: Frederic Crozat (fcrozat) (2010-11-04 07:57:41) (reply to #14)
Your statement is incorrect :
DKMS allows to create both binary and source packages (Mandriva /
Mageia) has been the first distribution to ship DKMS modules, with both
modes :
- on some spins of the distributions, binary rpm (similar to KMP) were
used, not requiring gcc and source package
- on other spins (Cooker which is similar to factory), source package
with automatic recompilation of module was available.
And I took care of not slowing boot time when DKMS was used.

#17: Jan Engelhardt (jengelh) (2010-08-19 20:38:47) (reply to #13)
Longer boot time? I can see the complaints coming already..

#18: Jean-Daniel Dodin (jdd) (2010-10-18 17:20:05)
problem is that KMP modules are *not* provided for virtualbox/ATI-
AMD/NVIDIA proprietary drivers, so each kernel update *break* the
config.
dkms could be provided as an option

#19: Susanne Oberhauser (froh) (2010-10-19 11:20:38) (reply to #18)
problem of that problem is that we only redistribute open source
software.
solution is to have the kmp repositories set up at pacman or similar
less restrictive build services.
then a rebuild of the kernel triggers a rebuild of the KMP and an
update will get a matching KMP.

#20: Rajko Matovic (rajko_m) (2010-11-04 05:45:07) (reply to #19)
Non-oss repo is what? Do we distribute that? IMHO, yes.  :-)
DKMS will solve:
* KMP doesn't work on my  machine problem.
* It will prevent 11.3 pain where Nvidia and ATI KMPs came week, or so,
after release. 
* There is no VirtualBox source for rpm from Oracle, and some people
need USB functionality.
* Recompilation of some opensource drivers for seldom used hardware
that user has to compile, or learn how to make KMP package by himself. 
* Lower pressure in support channels when something goes haywire. 
* Lower download volume for all kernel-devel, source, and bunch of
other devel packages. 
and so many other problems that we can't even predict. 
Using DKMS does not prevent creation of KMPs. 
Broken kernel problems is easy to solve if kernel installation does not
remove old working kernel.
The same is with modules. If we want DKMS to be user friendly, then we
will create backup and boot option to revert last kernel changes.
BTW, KMPs can be broken on some hardware, despite well done test phase,
so having ability to revert last changes is not related to DKMS only. 
 
 
 

#22: Alberto Passalacqua (greengeeko) (2010-11-06 05:20:19) (reply to
#18)
Actually KMP's *are* provided for nVidia and ATI drivers. And virtualbox
shipped
(ose release) with openSUSE has them too. I find KMP a cleaner and more
elegant solution too, compared to forcing the installation of
compilers, kernel sources and all the bits required to make DKMS work.

#23: Frederic Crozat (fcrozat) (2010-11-08 09:56:03) (reply to #22)
DKMS doesn't require installing compiler and so on, you can perfectly
use it in a KMP like mode.



--
openSUSE Feature:
https://features.opensuse.org/305148

< Previous Next >
This Thread
  • No further messages