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.patc...
> -- 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...
> (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.
Dan
> > 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