Now after FESCO granted resurrection and enable by default of DKMS I've been researching and scratching my head bit over this one what 5 years ago LF created working group with representatives from Novell, RH, Canonical,Dell and IBM which comes up with kmp
The outcome of this is amongst other things...
* kmp rpm macros [1] * Jockey [2] * driver db spec being created [1]
Suse rejects dkms inclusion in the distribution [4]
Comment from S.O in that suse request
"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."
"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."
This indicates that we should not be shipping dkms et all so does anyone know anything about the current status on this in the working group?
What our ( project ) status is in this?
What the way forward is supposed to be?
JBG
1. http://www.linuxfoundation.org/collaborate/workgroups/driver-backport/kmp_ma...
2. https://launchpad.net/jockey 3. http://www.linuxfoundation.org/collaborate/workgroups/driver-backport/online... 4. https://features.opensuse.org/305148
On Tue, Jul 02, 2013 at 09:26:38PM +0000, "Jóhann B. Guðmundsson" wrote:
This indicates that we should not be shipping dkms et all so does anyone know anything about the current status on this in the working group?
DKMS is a framework for rebuilding modules when a new kernel is installed. It is primarily targeted at enterprise distributions. If someone wants to package and maintain it for Fedora, then I guess that's a thing they can do.
What our ( project ) status is in this?
Fedora the project doesn't have any status in DKMS at all.
What the way forward is supposed to be?
Fedora's approach is to get drivers upstream and they'll naturally get picked up when we rebase. We don't provide or ship any pre-built out-of-tree modules, nor do we support dkms, kmods, or any of the other module building frameworks from a kernel perspective. Those are supported by the additional persons or repositories that provide them.
josh
On 07/03/2013 12:50 AM, Josh Boyer wrote:
On Tue, Jul 02, 2013 at 09:26:38PM +0000, "Jóhann B. Guðmundsson" wrote:
This indicates that we should not be shipping dkms et all so does anyone know anything about the current status on this in the working group?
DKMS is a framework for rebuilding modules when a new kernel is installed. It is primarily targeted at enterprise distributions. If someone wants to package and maintain it for Fedora, then I guess that's a thing they can do.
I would have thought the kernel community frowned making it available for end user system.
What our ( project ) status is in this?
Fedora the project doesn't have any status in DKMS at all.
Meant to say stance not status ;)
What the way forward is supposed to be?
Fedora's approach is to get drivers upstream and they'll naturally get picked up when we rebase. We don't provide or ship any pre-built out-of-tree modules, nor do we support dkms, kmods, or any of the other module building frameworks from a kernel perspective. Those are supported by the additional persons or repositories that provide them.
Interesting it comes logically to me that we should have aligned ourselves with opensuse and the working group stance and only make it available as an build service to provide developer build of backported modules, or modules that are on their way into mainline for testing purposes only you know assist those that are willing to go through steps necessary to making it into mainline ( while doing the opposite for those that dont as in making it harder since they would have to carry dkms themselves those usually have questionable license anyway )
In anycase FESCO did not even bother looking into the unit [1] before allowing dkms to be enabled by default ( that unit will never work in it's current shape and obviously was not even tested before being asked to be enabled by default ) so I would not act surprised when dkms bugs or 3rd party modules don't build correctly get accidental misfiled against the kernel.
JBG
1. http://pkgs.fedoraproject.org/cgit/dkms.git/tree/dkms.service
On Wed, Jul 03, 2013 at 03:14:02AM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/03/2013 12:50 AM, Josh Boyer wrote:
On Tue, Jul 02, 2013 at 09:26:38PM +0000, "Jóhann B. Guðmundsson" wrote:
This indicates that we should not be shipping dkms et all so does anyone know anything about the current status on this in the working group?
DKMS is a framework for rebuilding modules when a new kernel is installed. It is primarily targeted at enterprise distributions. If someone wants to package and maintain it for Fedora, then I guess that's a thing they can do.
I would have thought the kernel community frowned making it available for end user system.
Oh, I'm sure none of us actually like it in terms of Fedora. But we can't prevent people from doing every little thing that we don't like and the kernel taints as out-of-tree if someone loads a module with dkms.
What the way forward is supposed to be?
Fedora's approach is to get drivers upstream and they'll naturally get picked up when we rebase. We don't provide or ship any pre-built out-of-tree modules, nor do we support dkms, kmods, or any of the other module building frameworks from a kernel perspective. Those are supported by the additional persons or repositories that provide them.
Interesting it comes logically to me that we should have aligned ourselves with opensuse and the working group stance and only make it available as an build service to provide developer build of backported modules, or modules that are on their way into mainline for testing purposes only you know assist those that are willing to go through steps necessary to making it into mainline ( while doing the opposite for those that dont as in making it harder since they would have to carry dkms themselves those usually have questionable license anyway )
Fedora isn't really a company like Novell or IBM. I have no idea if the work group reached out to Red Hat at all, but that doesn't matter much either in regards to Fedora.
We did carry, as part of the kernel package itself, the precursor to the driver-backports project in the 3.6 timeframe. John Linville used the compat-wireless tarballs, which are basically backports of the latest upstream wireless bits and that's what we shipped for wireless drivers for quite a while. It wasn't the greatest success from a distribution standpoint. Lots of bugs were hit, and explaining to upstream people that things were backported was both confusing and frustrating.
In anycase FESCO did not even bother looking into the unit [1] before allowing dkms to be enabled by default ( that unit will never work in it's current shape and obviously was not even tested before being asked to be enabled by default ) so I would not act surprised when dkms bugs or 3rd party modules don't build correctly get accidental misfiled against the kernel.
We're used to that. Honestly, I don't believe DKMS is used widely enough to even worry about it. I can't recall the last time I saw a bug report about a failing module or module build that involved anything other than rpmfusion kmods and/or virtual box.
josh
kernel@lists.fedoraproject.org