[opensuse-kernel] 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-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 01:09 PM, Larry Finger wrote:
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.
Well, "too much effort" is relative. Our kernel teams are currently doing maintenance for multiple code streams as well as developing SLE11 SP1 and openSUSE 11.3. I'm sure you can imagine where backporting the staging drivers falls on the list of priorities. Pulling direct from mainline doesn't work since our git repo isn't an expanded tree. It's a repository of patches that get applied in sequence. Backporting the drivers means manually cherry picking out the changes and rolling them into patches that apply to our tree. This makes it painful for things like this, but has _huge_ advantages in other areas. What I meant by accepting pull requests is that if someone finds a driver that has changes that fixes an issue they're observing on their own hardware and wants to put the effort into backporting the patch into their own copy of our git repo, I wouldn't be opposed to accepting it into our repo. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksn1zUACgkQLPWxlyuTD7JSZwCfUVG0Ku0oBCqTP53Lmi+hIAY3 BAAAoIDnGA8BPHb7VvDRDlt8DAKVGCV9 =4VdZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+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-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 02:06 PM, Stefan Seyfried wrote:
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!
If you want the super duper bleeding edge, add the Kernel:HEAD repo. It is the devel project for the openSUSE:Factory kernel. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksn3pUACgkQLPWxlyuTD7J9LgCfQt2S007UKyGIxj0XDY1BSZ37 6bUAn3EM+S8/07Xv/q+3AAQrhYE2WlUp =9qdN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 02:06 PM, Stefan Seyfried wrote:
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)
Yep. That's definitely an option, but ends up actually being more work than just adding it to the tree. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksn3rMACgkQLPWxlyuTD7LbRwCbBSzsxQigV6m8kEyugF+qHSam gSgAnRbbn52WuQmSx6bFfjVaL1xSEZ74 =s294 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le mardi 15 décembre 2009 20:08, Jeff Mahoney a écrit :
On 12/15/2009 02:06 PM, Stefan Seyfried wrote:
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)
Yep. That's definitely an option, but ends up actually being more work than just adding it to the tree.
But it offers a much higher degree of flexibility. You can provide several versions of the driver for different categories of users, and they can switch easily if anything goes wrong. If building KMPs is hard, then maybe we should work at making it easier. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jean Delvare píše v St 16. 12. 2009 v 11:19 +0100:
Le mardi 15 décembre 2009 20:08, Jeff Mahoney a écrit :
On 12/15/2009 02:06 PM, Stefan Seyfried wrote:
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)
Yep. That's definitely an option, but ends up actually being more work than just adding it to the tree.
But it offers a much higher degree of flexibility. You can provide several versions of the driver for different categories of users, and they can switch easily if anything goes wrong.
If building KMPs is hard, then maybe we should work at making it easier.
Ah, eat your own dogfood. Yes. I couldn't agree more. Petr Tesarik -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 16.12.2009 11:19, Jean Delvare wrote:
Le mardi 15 décembre 2009 20:08, Jeff Mahoney a écrit :
On 12/15/2009 02:06 PM, Stefan Seyfried wrote:
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)
Yep. That's definitely an option, but ends up actually being more work than just adding it to the tree.
But it offers a much higher degree of flexibility. You can provide several versions of the driver for different categories of users, and they can switch easily if anything goes wrong.
And receive several categories of bugreports..? I mean, KMPs are great for modules that for various reasons (supportability, legal issues) can't be part of the kernel package. But creating more KMPs just because we can?
If building KMPs is hard, then maybe we should work at making it easier.
Agreed, but if the code is going to be taken care of by the same people who take care of the kernel (at least this is how I read Jeff's proposal), then no matter how we try, maintaining the kernel + dozen of KMPs will never be easier than maintaining everything on one place. Think of e.g. fixes in driver subsystems that affect both core code and the drivers - having to fix such things in multiple packages is not gonna be fun. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
At Wed, 16 Dec 2009 12:13:56 +0100, Michal Marek wrote:
If building KMPs is hard, then maybe we should work at making it easier.
Agreed, but if the code is going to be taken care of by the same people who take care of the kernel (at least this is how I read Jeff's proposal), then no matter how we try, maintaining the kernel + dozen of KMPs will never be easier than maintaining everything on one place. Think of e.g. fixes in driver subsystems that affect both core code and the drivers - having to fix such things in multiple packages is not gonna be fun.
One merit of KMP is the quickness of update. In general, the update rate of kernel is relatively slow. If you find a crash bug in the driver code and fix it in the kernel tree, the official update is postponed. With KMP, it could be handled more quickly. Of course, there are lots of downside of KMP, and keeping everything in the kernel update is ideal. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 16.12.2009 12:57, Takashi Iwai wrote:
At Wed, 16 Dec 2009 12:13:56 +0100, Michal Marek wrote:
If building KMPs is hard, then maybe we should work at making it easier.
Agreed, but if the code is going to be taken care of by the same people who take care of the kernel (at least this is how I read Jeff's proposal), then no matter how we try, maintaining the kernel + dozen of KMPs will never be easier than maintaining everything on one place. Think of e.g. fixes in driver subsystems that affect both core code and the drivers - having to fix such things in multiple packages is not gonna be fun.
One merit of KMP is the quickness of update.
Right, that's an advantage. But you can create the KMP when there is real need for such fast update, it doesn't have to be delivered as KMP from the very start. Also, I don't think this is relevant to what Jeff is proposing, the step forward is to have the drivers available at all, not to update them as fast as possible. In short, KMPs are a good solution to some problems, but when there is no problem, why bother solving it :). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/16/2009 05:19 AM, Jean Delvare wrote:
Le mardi 15 décembre 2009 20:08, Jeff Mahoney a écrit :
On 12/15/2009 02:06 PM, Stefan Seyfried wrote:
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)
Yep. That's definitely an option, but ends up actually being more work than just adding it to the tree.
But it offers a much higher degree of flexibility. You can provide several versions of the driver for different categories of users, and they can switch easily if anything goes wrong.
If building KMPs is hard, then maybe we should work at making it easier.
It's not that it's hard, it's that it's time consuming. Short of making an automated interface to the build service to do all of this for us, that doesn't change. There is one advantage that I had overlooked. Users can create their own KMPs and submit requests for inclusion into a special Kernel:Extras project or something with very little interaction from the kernel teams. On the other hand, now with the public git repo, the same is possible with just adding a kernel patch. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkspDs8ACgkQLPWxlyuTD7LoGwCgn8v6XeYaeU4TsKEwwSj6tbkr zJQAmwYi5Zu6qKHAMbDeAmCF2Bv/6oYu =mqFX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (8)
-
Greg KH -
Jean Delvare -
Jeff Mahoney -
Larry Finger -
Michal Marek -
Petr Tesarik -
Stefan Seyfried -
Takashi Iwai