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. 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 > _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
