Enabling drivers in staging tree in rawhide

Dan Williams dcbw at redhat.com
Thu Jan 8 16:14:04 UTC 2009

On Thu, 2009-01-08 at 10:35 -0500, Dave Jones wrote:
> On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
>  > Related: I raised the staging problem already in
>  > https://bugzilla.redhat.com/show_bug.cgi?id=477927
>  > as rawhide contained the at76 driver as separate patch
>  > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup
>  > -- but the same driver (with two small changes) also was part of the 
>  > upstream kernel since October/2.6.28-rc as one of the staging drivers:
>  > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08
>  > (for more details see bug).
>  > 
>  > That sounds wrong to me, as
>  > 
>  > - it's duplicated work
>  > 
>  > - the at76 staging driver from upstream taints the kernel; the driver 
>  > from our patch doesn't.
> The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville.
> I don't know the backstory behind at76, but it's been lingering for
> quite a while, and it would be nice to see it go away yes.
> I'm not clear on why this is going through -staging instead of wireless-dev either.

I would *not* recommend adding RTL staging driver at this time.  There's
a reason it wasn't imported into the actual kernel in the first place.
-staging is a bad idea for precisely the reason we're talking about this
now: it gives legitimacy to drivers of questionable quality.  While it
may make peoples hardware somewhat work, it certainly doesn't help make
the system as a whole work *better*, because the drivers don't
necessarily implement everything that, for example, wpa_supplicant or
NetworkManager expect, or v4l2, or whatever.

Does it use the in-kernel rfkill layer?  Does it have correct locking
and everything?  Does it use the *standard kernel wireless stack*?  The
answer to at least two of these is "no", which is why it's not approved
by the wireless developers yet, and never will be.

Just because a driver makes hardware work, doesn't mean it makes
hardware work *well* or play well with everything else.


>  > > The ralink wireless drivers for example would hopefully make the newer 
>  > > EEE PC model would out of the box.  Does it make sense to enable the 
>  > > drivers in staging tree by default and bring more exposure to them 
>  > > atleast via rawhide if not in general releases?
>  > 
>  > +1 to the "I think providing hardware support in rawhide and then 
>  > removing it  before release would be somewhat user-hostile." comment 
>  > from mjg59.
>  > 
>  > IOW: Either enable or disable them. I'm unsure myself what to do but I 
>  > tend to say that disabling the whole staging drivers might be the best 
>  > for Fedora (Greg calls himself as "maintainer of crap" for a good reason).
>  > @Davej, Cebbert and Kylem: What's your position on this?
> I don't think we can make a carte-blanche statement to say "no we won't do this ever".
> The quality of the drivers that end up there are going to vary, and for some,
> if it's for a piece of hardware that's really popular, it may make sense
> to enable it.  As long as doing so doesn't cause us headaches down the line.
> I'm not overly against the idea of enabling something with the caveat
> that we have someone responsible for working on it, with the goal of
> getting it out of staging, and dealing with bugs etc.
> Not unlike the same reasoning for us adding various not-yet-upstream drivers
> to the Fedora kernel really.
> But it's really going to be a case-by-case thing I think. 
> 	Dave
> -- 
> http://www.codemonkey.org.uk

More information about the fedora-devel-list mailing list