On Wed, Feb 09, 2011 at 11:18:42AM -0500, Jeff Mahoney wrote:
On 02/09/2011 11:07 AM, Greg KH wrote:
On Wed, Feb 09, 2011 at 10:36:38AM -0500, Jeff Mahoney wrote:
Hi all -
One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely.
One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough.
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions:
1) Move staging drivers to a separate package that isn't installed by default
I wouldn't object to this, but it seems a bit harsh as for some systems, we even support staging drivers to some customers (yeah, I know this doesn't matter to openSUSE, but not all staging drivers are "bad", some are there for a variety of reasons, not the least being I forgot to move them to the "main" portion of the kernel tree...)
2) Issue a warning during install or first driver load that the driver is of dubious quality
That happens already, so you don't have to do anything new here :)
I don't mean dumping a short message to the kernel log. I mean real integration into the UI so that the user doesn't have to hunt for it. Toss a message on dbus (or whatever) so it pops up in the GUI.
That might be hard when those drivers get loaded in the initrd, like a number of them do today. I have a laptop here that oopses on the latest FACTORY/Tumbleweed kernel because of this issue, I need to get a patch into the next -stable update to resolve it, so I understand the problem, but issuing a dbus message wouldn't help a user out who happens to have a machine that doesn't boot.
3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything
6) Assign all staging driver bugs to me?
That works for me. :)
Seriously, I'm fine with this, assign away. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org