CCing fedora-kernel
On 08.01.2009 03:49, Rahul Sundaram wrote:
Quite a bit of new drivers in http://lwn.net/Articles/313730/
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?v... -- 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=... (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 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?
If they are disabled completely in Fedora then I'll nevertheless consider to create a "kmod-staging" package for RPM Fusion.
CU knurd
On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
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 was largely ignoring staging/ for maintainability reasons, but if there's sufficient demand I can take a look at enabling some of it on a case by case basis, as long as it won't cause a tragic amount of grief for everyone.
regards, Kyle
On Thu, 2009-01-08 at 10:31 -0500, Kyle McMartin wrote:
On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
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 was largely ignoring staging/ for maintainability reasons, but if there's sufficient demand I can take a look at enabling some of it on a case by case basis, as long as it won't cause a tragic amount of grief for everyone.
The rtl driver has it's own 802.11 stack, just like linux-wlan-usb does (p80211), which is also in staging. I don't think we really want to be maintaining twice as many wireless stacks going forward, do we? Basically, I'm going to ignore any issues that come in from these drivers because they aren't accepted upstream wireless drivers, despite what gregkh (who's not a wireless developer) tries to make them.
The upstream wireless people have made it clear that these drivers aren't acceptable in their current form, and it's unlikely either of these will be, given that they will essentially need a complete rewrite to use mac80211 (for rtl2860) and hostap (for linux-wlan-ng).
Dan
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?v... -- 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=... (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.
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
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?v... -- 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=... (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
On Thu, Jan 08, 2009 at 10:35:42AM -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?v... -- 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=... (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.
at76 looked like it was going to have a working mac80211-based version some time ago. The mac80211 port happened, but it broke the driver... :-(
The version in -staging actually came from the Fedora kernel, so enabling it and dropping our patch isn't such a bad idea. I was concerned that the busted mac80211 port of it might come back (and it seem to have done so for now in 2.6.29), so I was leaning against it. (I'm still mostly against that unless we can get the mac80211 port backed-out of 2.6.29...)
Now Kalle Valo says he is working on a new mac80211 port of that driver, and that he intends to rename it to avoid confusion. I presume that will get to Linus through my trees when it becomes available and hopefully at76_usb will disappear from -staging then.
Does that clear-up anything? :-)
John
kernel@lists.fedoraproject.org
-
Dan Williams -
Dave Jones -
John W. Linville -
Kyle McMartin -
Thorsten Leemhuis