-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2011 11:24 AM, Greg KH wrote:
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.
Most of the staging driver issues I've seen aren't boot-related. The system comes up fine and then some device isn't operating properly. It'd be nice to let the user know that ahead of time. The more I think about, you're right about tossing a message on dbus during boot wouldn't work - -- devices are probably all initialized before the UI comes up. Perhaps a bit of post-processing in a script that runs after xdm. *shrug* - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SwuYACgkQLPWxlyuTD7I2PgCcDQA1B6frKTavbKjBd/LnI8CB mKUAoJex2yIUAnumoumInKXjjO4rsl4g =Oy9K -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org