[opensuse-factory] Hardware enablement in kernel updates
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - Some of you have seen my posts on this list before, but it may not be clear what my involvement is with kernel development. I lead one of the kernel teams in SUSE Labs. I maintain the master branch of the SUSE kernel trees (both SLE and openSUSE) and have been the release manager for the kernel for the past few openSUSE releases (as well as a few enterprise releases). Historically, some decisions have been made that affect the openSUSE kernel collaboratively, but not entirely transparently, and I'd like to change that. One of our policies regarding kernel updates is that we'll fix bugs pertaining to usability until the next release. Otherwise, it's security, data loss/corruption, and system crash fixes until EOL. While it could be argued that hardware enablement falls under usability, we haven't treated it that way in the past. I'd like to revisit that. I was asked today about the possibility of adding a driver to the 11.2 kernel, and I started thinking about it. Strictly speaking, it's against our inclusion policy. However, the new longer release cycle means that users with new hardware may be forced to run a Factory kernel on 11.2, switch to a different distribution, or wait around until the next release. While I don't personally have a problem with option #1, I'm a kernel hacker and kernel bugs don't scare me. Not everyone wants to be a beta tester. Option #2 isn't in the long-term interests of the openSUSE community. Option #3 is painful because it means that you have this shiny new hardware for which you've paid your hard-earned money and can't use to its fullest potential. The particular driver I was asked about is completely standalone. I don't have a problem including it since it won't affect anything else. The issue was that I don't want to encourage the expectation that this would be a normal occurrence - unless we want to change the policy surrounding updates. I should be clear on what I have in mind and what the limitations are. I do not intend to open the door for every crap driver that's floating around out there. There are reasons that the drivers aren't in the mainline kernel and I have no interest in duplicating that debate on this list. Drivers up for post-release inclusion _must_ be already in the mainline kernel. The other limitation is that the changes be completely standalone or isolated such that it's apparent that the introduction of the change doesn't affect the stability of users who are using those drivers already. That part can get sticky since adding a PCI ID is easy, but adding handling that is needed to enable that PCI ID while potentially affecting other devices in a clean way is not. So with that, I'd like to open it up for discussion. I've cross-posted between opensuse-factory and opensuse-kernel since it's a policy that affects everyone, not just those interested in the kernel itself. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksm4ecACgkQLPWxlyuTD7LD7QCeK9lDtJo6h/LcRnfng93+i0Pc Hv0An2Wnb1N41xxLSQjB830w1SwGdiUQ =Fwo1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, On Mon, Dec 14, Jeff Mahoney wrote:
One of our policies regarding kernel updates is that we'll fix bugs pertaining to usability until the next release. Otherwise, it's security, data loss/corruption, and system crash fixes until EOL. While it could be argued that hardware enablement falls under usability, we haven't treated it that way in the past.
Well, that depends on your definition of "past" :)
I'd like to revisit that.
[...]
The particular driver I was asked about is completely standalone. I don't have a problem including it since it won't affect anything else.
So just go ahead. You will not hurt anybody, but chances are you will make some people happy.
The issue was that I don't want to encourage the expectation that this would be a normal occurrence - unless we want to change the policy surrounding updates.
Making people happy is a good thing.
I should be clear on what I have in mind and what the limitations are. I do not intend to open the door for every crap driver that's floating around out there. There are reasons that the drivers aren't in the mainline kernel and I have no interest in duplicating that debate on this list. Drivers up for post-release inclusion _must_ be already in the mainline kernel.
There was a time (in the real past) when users chose the SuSE kernel over mainline because it supported much more hardware...
The other limitation is that the changes be completely standalone or isolated such that it's apparent that the introduction of the change doesn't affect the stability of users who are using those drivers already. That part can get sticky since adding a PCI ID is easy, but adding handling that is needed to enable that PCI ID while potentially affecting other devices in a clean way is not.
This limitation is understandable.
So with that, I'd like to open it up for discussion. I've cross-posted between opensuse-factory and opensuse-kernel since it's a policy that affects everyone, not just those interested in the kernel itself.
-Jeff
Hubert "using the out-of-mainline lirc driver since years" Mantel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Il martedì 15 dicembre 2009, Hubert Mantel scrisse:
Hi,
On Mon, Dec 14, Jeff Mahoney wrote:
One of our policies regarding kernel updates is that we'll fix bugs pertaining to usability until the next release. Otherwise, it's security, data loss/corruption, and system crash fixes until EOL. While it could be argued that hardware enablement falls under usability, we haven't treated it that way in the past.
Well, that depends on your definition of "past" :)
I'd like to revisit that.
[...]
The particular driver I was asked about is completely standalone. I don't have a problem including it since it won't affect anything else.
So just go ahead. You will not hurt anybody, but chances are you will make some people happy. I agree, Extending hardware support is always a good thing. Obviously without breaking existing one :) There should be updates for staging drivers too, not only for new hardware.. bye.
-- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Dec 15, 2009 at 06:28:34PM +0100, Daniele wrote:
There should be updates for staging drivers too, not only for new hardware..
If you have a specific staging driver that you want updated, please let me know. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Il martedì 15 dicembre 2009, Greg KH scrisse:
On Tue, Dec 15, 2009 at 06:28:34PM +0100, Daniele wrote:
There should be updates for staging drivers too, not only for new hardware..
If you have a specific staging driver that you want updated, please let me know. Hi Greg, rt2860 is a good candidate for un update (#561610). On obs there is a x64 version but not i586. Bye.
-- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Dec 15, 2009 at 07:37:11PM +0100, Daniele wrote:
Il martedì 15 dicembre 2009, Greg KH scrisse:
On Tue, Dec 15, 2009 at 06:28:34PM +0100, Daniele wrote:
There should be updates for staging drivers too, not only for new hardware..
If you have a specific staging driver that you want updated, please let me know. Hi Greg, rt2860 is a good candidate for un update (#561610).
It's easier to add a whole new driver, than update an existing one. If you can confirm that the version in 2.6.32 works properly, I'll consider backporting the changes. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Il martedì 15 dicembre 2009, Greg KH scrisse:
On Tue, Dec 15, 2009 at 07:37:11PM +0100, Daniele wrote:
Il martedì 15 dicembre 2009, Greg KH scrisse:
On Tue, Dec 15, 2009 at 06:28:34PM +0100, Daniele wrote:
There should be updates for staging drivers too, not only for new hardware..
If you have a specific staging driver that you want updated, please let me know.
Hi Greg, rt2860 is a good candidate for un update (#561610).
It's easier to add a whole new driver, than update an existing one.
If you can confirm that the version in 2.6.32 works properly, I'll consider backporting the changes. I didn't try but: http://lists.opensuse.org/opensuse-bugs/2009-12/msg03737.html
Bye. -- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Dec 15, 2009 at 08:38:01PM +0100, Daniele wrote:
Il martedì 15 dicembre 2009, Greg KH scrisse:
On Tue, Dec 15, 2009 at 07:37:11PM +0100, Daniele wrote:
Il martedì 15 dicembre 2009, Greg KH scrisse:
On Tue, Dec 15, 2009 at 06:28:34PM +0100, Daniele wrote:
There should be updates for staging drivers too, not only for new hardware..
If you have a specific staging driver that you want updated, please let me know.
Hi Greg, rt2860 is a good candidate for un update (#561610).
It's easier to add a whole new driver, than update an existing one.
If you can confirm that the version in 2.6.32 works properly, I'll consider backporting the changes. I didn't try but: http://lists.opensuse.org/opensuse-bugs/2009-12/msg03737.html
I have no idea if that is relevant or not. Please try the 2.6.32 kernel out and let me know if it works or not for you. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 12/14/2009 07:09 PM, Jeff Mahoney wrote: I think this is a good idea. The current policy heavily penalizes the user whose hardware was supported by the kernel that was released just after the distro was frozen. Most of my activity is with wireless drivers, which have many changes with each kernel release, as well as manufacturers releasing new hardware on a regular basis. For me, kernel 2.6.32 is much more usable than 2.6.31 because one of my devices is a Broadcom BCM4312. It must be said, however, that the changes needed to support that chip are likely to be too invasive to fit under your guidelines. That will be the hardest part of implementing the proposed changes - how invasive can the changes be? Does your proposed new policy automatically exclude those drivers in staging? Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Dec 15, 2009 at 11:20:21AM -0600, Larry Finger wrote:
On 12/14/2009 07:09 PM, Jeff Mahoney wrote:
I think this is a good idea. The current policy heavily penalizes the user whose hardware was supported by the kernel that was released just after the distro was frozen. Most of my activity is with wireless drivers, which have many changes with each kernel release, as well as manufacturers releasing new hardware on a regular basis.
For me, kernel 2.6.32 is much more usable than 2.6.31 because one of my devices is a Broadcom BCM4312. It must be said, however, that the changes needed to support that chip are likely to be too invasive to fit under your guidelines. That will be the hardest part of implementing the proposed changes - how invasive can the changes be?
Does your proposed new policy automatically exclude those drivers in staging?
I hope not, as the driver I wanted to add is in the staging directory :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 12:20 PM, Larry Finger wrote:
On 12/14/2009 07:09 PM, Jeff Mahoney wrote:
I think this is a good idea. The current policy heavily penalizes the user whose hardware was supported by the kernel that was released just after the distro was frozen. Most of my activity is with wireless drivers, which have many changes with each kernel release, as well as manufacturers releasing new hardware on a regular basis.
For me, kernel 2.6.32 is much more usable than 2.6.31 because one of my devices is a Broadcom BCM4312. It must be said, however, that the changes needed to support that chip are likely to be too invasive to fit under your guidelines. That will be the hardest part of implementing the proposed changes - how invasive can the changes be?
Does your proposed new policy automatically exclude those drivers in staging?
I'm not sure what you mean here. Do you mean updating staging/ drivers or adding new ones? I have no problem adding new staging/ drivers. They definitely fit the "standalone" requirement. I don't have any objections to revving staging/ drivers in general. Most changes will only improve their quality. I don't really want to say that it will happen automatically, though. That ends up being quite a lot of work for kernel teams that are already heavily overloaded. OTOH, now that we have a public git repo, I wouldn't be opposed accepting pull requests that rev staging drivers. There are a lot of things we could end up doing that we haven't in the past if we have more community involvement. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksnyv4ACgkQLPWxlyuTD7IJRQCfc61FWCNe6gM6skHmdJspnv6Q 3FYAn1uJVPO4iOpeD2KMTut7BdrZB9JE =Fn7P -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Il martedì 15 dicembre 2009, Jeff Mahoney scrisse: ..
Does your proposed new policy automatically exclude those drivers in staging?
I'm not sure what you mean here. Do you mean updating staging/ drivers or adding new ones? I have no problem adding new staging/ drivers. They definitely fit the "standalone" requirement. For me both. A "maybe working driver" is better then a missing driver. Half working driver is better than a "maybe working driver" and so on.. So, why not ? Bye.
-- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 12/15/2009 11:44 AM, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/15/2009 12:20 PM, Larry Finger wrote:
On 12/14/2009 07:09 PM, Jeff Mahoney wrote:
I think this is a good idea. The current policy heavily penalizes the user whose hardware was supported by the kernel that was released just after the distro was frozen. Most of my activity is with wireless drivers, which have many changes with each kernel release, as well as manufacturers releasing new hardware on a regular basis.
For me, kernel 2.6.32 is much more usable than 2.6.31 because one of my devices is a Broadcom BCM4312. It must be said, however, that the changes needed to support that chip are likely to be too invasive to fit under your guidelines. That will be the hardest part of implementing the proposed changes - how invasive can the changes be?
Does your proposed new policy automatically exclude those drivers in staging?
I'm not sure what you mean here. Do you mean updating staging/ drivers or adding new ones? I have no problem adding new staging/ drivers. They definitely fit the "standalone" requirement.
The question really was whether your phrase "mainline drivers" included those in "staging". From what you say below, it obviously does.
I don't have any objections to revving staging/ drivers in general. Most changes will only improve their quality. I don't really want to say that it will happen automatically, though. That ends up being quite a lot of work for kernel teams that are already heavily overloaded.
OTOH, now that we have a public git repo, I wouldn't be opposed accepting pull requests that rev staging drivers. There are a lot of things we could end up doing that we haven't in the past if we have more community involvement.
With git, the pull from staging shouldn't cause the kernel teams too much effort to get them to build. The fact that driver is in staging removes a lot of guarantees. In addition, those drivers are generally in better shape than the initial version of the vendor's driver, which is likely the user's only other option. At least this is true for Realtek's rtl8187se driver. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Good day everybody, can't you just create an obs repository which is semi official? Kernel:Extra- Modules for example? This will make it easy for people to add support for non out of the 11.2 box hardware and otherwise keep the stock kernel clear. Karsten Am Dienstag, 15. Dezember 2009 02:09:59 schrieb Jeff Mahoney:
Hi all -
Some of you have seen my posts on this list before, but it may not be clear what my involvement is with kernel development. I lead one of the kernel teams in SUSE Labs. I maintain the master branch of the SUSE kernel trees (both SLE and openSUSE) and have been the release manager for the kernel for the past few openSUSE releases (as well as a few enterprise releases). Historically, some decisions have been made that affect the openSUSE kernel collaboratively, but not entirely transparently, and I'd like to change that.
One of our policies regarding kernel updates is that we'll fix bugs pertaining to usability until the next release. Otherwise, it's security, data loss/corruption, and system crash fixes until EOL. While it could be argued that hardware enablement falls under usability, we haven't treated it that way in the past. I'd like to revisit that.
I was asked today about the possibility of adding a driver to the 11.2 kernel, and I started thinking about it. Strictly speaking, it's against our inclusion policy. However, the new longer release cycle means that users with new hardware may be forced to run a Factory kernel on 11.2, switch to a different distribution, or wait around until the next release.
While I don't personally have a problem with option #1, I'm a kernel hacker and kernel bugs don't scare me. Not everyone wants to be a beta tester. Option #2 isn't in the long-term interests of the openSUSE community. Option #3 is painful because it means that you have this shiny new hardware for which you've paid your hard-earned money and can't use to its fullest potential.
The particular driver I was asked about is completely standalone. I don't have a problem including it since it won't affect anything else. The issue was that I don't want to encourage the expectation that this would be a normal occurrence - unless we want to change the policy surrounding updates.
I should be clear on what I have in mind and what the limitations are. I do not intend to open the door for every crap driver that's floating around out there. There are reasons that the drivers aren't in the mainline kernel and I have no interest in duplicating that debate on this list. Drivers up for post-release inclusion _must_ be already in the mainline kernel. The other limitation is that the changes be completely standalone or isolated such that it's apparent that the introduction of the change doesn't affect the stability of users who are using those drivers already. That part can get sticky since adding a PCI ID is easy, but adding handling that is needed to enable that PCI ID while potentially affecting other devices in a clean way is not.
So with that, I'd like to open it up for discussion. I've cross-posted between opensuse-factory and opensuse-kernel since it's a policy that affects everyone, not just those interested in the kernel itself.
-Jeff
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 01:40 PM, Karsten König wrote:
Good day everybody,
can't you just create an obs repository which is semi official? Kernel:Extra- Modules for example?
This will make it easy for people to add support for non out of the 11.2 box hardware and otherwise keep the stock kernel clear.
There are already a few repos for things like that under drivers:<subsystem> So, yes, it's possible to do that now... except it ends up being _more_ work than just adding them to to the kernel package since it means creation of a new package for each one instead of just adding some patches to the kernel-source package. Not to mention that users would need to figure out which repo held the driver they're looking for. I guess your suggestion of a unified Kernel:Extra-Modules project full of _link packages would solve that issue, though. As far as user experience goes, I'm more concerned with "easy" than "possible." - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksn2pgACgkQLPWxlyuTD7K8KQCgheSKRHuLptWsExgENi1Qc6dG zmIAn0dsKKKfBaHOu0iQpR7e60EWqSIB =UIAR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-12-15 at 13:51 -0500, Jeff Mahoney wrote:
On 12/15/2009 01:40 PM, Karsten König wrote:
Good day everybody,
can't you just create an obs repository which is semi official? Kernel:Extra- Modules for example?
This will make it easy for people to add support for non out of the 11.2 box hardware and otherwise keep the stock kernel clear.
There are already a few repos for things like that under drivers:<subsystem>
...
Not to mention that users would need to figure out which repo held the driver they're looking for. I guess your suggestion of a unified Kernel:Extra-Modules project full of _link packages would solve that issue, though.
A project for all aditions would be a better compromise, IMHO, than altering the mainline kernel. Why? I can think of two reasons. 1) The mainline kernel could break: many of us want stability. 2) Download size, many updates to mainline kernel. Having a separate repo for these additions would make it easy for us users to choose whether we want the additions or not. And then the decission to create the aditions on your side would not have dangers, so go ahead :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksoIIsACgkQtTMYHG2NR9VHYgCfVQpvDwIwsya1DZUVxz43ABi2 q2IAn3iREc5WNERgNRMFLzKslMPlcBjN =kSI7 -----END PGP SIGNATURE-----
On Wed, 16 Dec 2009 00:49:25 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
2) Download size, many updates to mainline kernel.
Not that much of an issue due to deltarpms. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2009-12-16 at 14:08 +0100, Stefan Seyfried wrote:
On Wed, 16 Dec 2009 00:49:25 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
2) Download size, many updates to mainline kernel.
Not that much of an issue due to deltarpms.
Kernel updates need a reboot. Not nice. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkso71cACgkQtTMYHG2NR9UcRQCeLw9lCJteomcjgys72tyHiaY9 uJsAoIXZH5fWCPGwp+hqPn8l+RWDcTUR =ffNk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 16/12/2009 15:31, Carlos E. R. a écrit :
Kernel updates need a reboot. Not nice.
didn't that sould desapear? I remember a thread discussing new kernels didn't anymore ask for reboot? jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi Jeff, first: I generally agree with Hubert: "making people happy is good". Additionally, I am not really affected as I am running FACTORY anyway ;) Just one question... On Mon, 14 Dec 2009 20:09:59 -0500 Jeff Mahoney <jeffm@suse.com> wrote:
The particular driver I was asked about is completely standalone. I don't have a problem including it since it won't affect anything else.
Then it should be easy to build it as a KMP and provide via the buildservice, shouldn't it? (I'm not saying that this is better for the user or anything, just pointing out that there is another option) ... and the time saved by not updating the boring old stable kernel of openSUSE could be spent by even more frequent kernel updates for FACTORY! :-P Have fun, seife -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (9)
-
Carlos E. R. -
Daniele -
Greg KH -
Hubert Mantel -
jdd -
Jeff Mahoney -
Karsten König -
Larry Finger -
Stefan Seyfried