Enabling drivers in staging tree in rawhide
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.
More information about the fedora-devel-list