Feature changed by: Susanne Oberhauser Feature #305148, revision 3 Title: Automatic Compiling of Kernel Modules openSUSE-11.2: New Priority Requester: Important Requested by: Andreas Jaeger 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. + Discussion: + #2: Susanne Oberhauser (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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305148

Feature changed by: Uli Bamberg (uli-b) Feature #305148, revision 12 Title: Automatic Compiling of Kernel Modules openSUSE-11.2: New Priority Requester: Important Requested by: Andreas Jaeger (a_jaeger) Interested: Mariusz Fik (fisiu) Interested: Stefan Behlert (sbehlert) + Interested: Uli Bamberg (uli-b) 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) 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305148

Feature changed by: Sebastian Siebert (Freespacer) Feature #305148, revision 14 Title: Automatic Compiling of Kernel Modules openSUSE-11.2: New Priority Requester: Important Requested by: Andreas Jaeger (a_jaeger) Interested: Karsten König (remur) Interested: Mariusz Fik (fisiu) + Interested: Sebastian Siebert (freespacer) Interested: Stefan Behlert (sbehlert) Interested: Uli Bamberg (uli-b) 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) 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305148

Feature changed by: Susanne Oberhauser (froh) Feature #305148, revision 19 Title: Automatic Compiling of Kernel Modules openSUSE-11.2: New Priority Requester: Important Requested by: Andreas Jaeger (a_jaeger) 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) 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. -- openSUSE Feature: https://features.opensuse.org/305148

Feature changed by: jpxviii jpxviii (jpxviii) Feature #305148, revision 27 Title: Automatic Compiling of Kernel Modules 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 + Priority + Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) 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) 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. -- openSUSE Feature: https://features.opensuse.org/305148

Feature changed by: Jan Engelhardt (jengelh) Feature #305148, revision 29 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 Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) 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) 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. + #17: Jan Engelhardt (jengelh) (2010-08-19 20:38:47) (reply to #13) + Longer boot time? I can see the complaints coming already.. -- openSUSE Feature: https://features.opensuse.org/305148

Feature changed by: Susanne Oberhauser (froh) Feature #305148, revision 32 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 Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) 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) 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. #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. -- openSUSE Feature: https://features.opensuse.org/305148

Feature changed by: Frederic Crozat (fcrozat) Feature #305148, revision 36 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 Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) 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) 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.        -- openSUSE Feature: https://features.opensuse.org/305148

Feature changed by: Frederic Crozat (fcrozat) Feature #305148, revision 39 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 Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) 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) 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

Feature changed by: Di Pe (dipe) Feature #305148, revision 41 Title: Automatic Compiling of Kernel Modules 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: Duplicate of #308323 + Master status: New 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

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305148, revision 44 Title: Automatic Compiling of Kernel Modules 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: Duplicate of #308323 - Master status: New + Master status: Rejected by Andreas Jaeger + reject date: 2012-09-04 12:41:15 + reject reason: moving to generic product Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Project Manager: Andreas Gruenbacher (agruen) 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