On Wed, 2008-10-29 at 09:30 -0700, Greg KH wrote: > On Wed, Oct 29, 2008 at 06:13:04AM -0400, Dan Williams wrote: > > On Tue, 2008-10-28 at 15:45 -0700, Greg KH wrote: > > > On Tue, Oct 28, 2008 at 07:35:52PM +0100, Johannes Berg wrote: > > > > On Tue, 2008-10-28 at 10:08 -0700, Greg KH wrote: > > > > > > > > > "Work on", or "USE". > > > > > > > > > > The problem is, users have this hardware, and they want to run Linux on > > > > > it. Many distros already support this hardware with the "crap" driver, > > > > > so we might as well add that to the kernel tree so they at least get the > > > > > latest "crap" so that users have an easier time of it. > > > > > > > > > > Now, the fact that there is a competing driver being developed outside > > > > > of the tree does make this a bit more complicated. However, as it > > > > > doesn't work yet, there's not much we can do about including it, right? > > > > > > > > > > So adding the driver to the "crap" tree makes users happy in that they > > > > > can use their hardware. I'll support the "crap" to a point, and no one > > > > > has to do any API changes to the drivers/staging/ tree either, I can > > > > > easily handle that. > > > > > > > > > > Then, when the "correct" driver is finished, I will drop the crap driver > > > > > at the same time the "correct" one is added to the tree. > > > > > > > > > > This way, everyone wins, right? > > > > > > > > Only if the point is "use" rather than "work on". As far as I understood > > > > about staging, the point was more "work on" which would direct effort to > > > > the wrong driver. > > > > > > I'm not going to turn away patches that people send me to get the stable > > > drivers cleaned up and in better shape. > > > > > > I've now added the rtl2860 driver to the staging tree with a big note > > > that any comments should be made to me only, and that the wireless > > > developers would really have people work on their driver instead to get > > > it into a mergable state. > > > > Who's going to support this driver now that you're essentially > > green-lighting distros to ship it? > > The same people that were supporting it yesterday, when the distros were > shipping it already :) > > And if the distros don't want to, I will, like everything else in the > staging tree (hint, see the MAINTAINER entry in the kernel tree...) > > If a distro doesn't want to enable it, then they will not do so, that is > their choice. > > > I seriously disagree with this decision to add rtl2860. Adding > > drivers like at76_usb is fine because those are the drivers that > > people should be working on. But adding crap code just because it > > gets people's hardware working, but that has NO FUTURE in the wireless > > tree, is misguided at best. > > Hm, so, you are really saying that if we get users hardware working, > that is a misguided effort? No, I'm saying we should be getting users hardware working with _quality_ code, not something that we just pulled in off the street and put some makeup on. > That's sad. It's also sad when the driver is crap, the users ask for help because we shipped them a crap driver, and we can't do anything about it. Just because it works doesn't mean it works well. > > If we just wanted to get everyone's hardware "working" [1], why aren't > > we shipping ndiswrapper? At least add a "TAINT_STAGING" flag so that > > when people _run_ the crappy code and report errors the wireless > > developers are aware of it right off the bat. > > I take it you haven't even looked at the staging tree. If you load any I have looked at the specific wireless drivers that you've added to staging to determine their quality, implementation of WEXT, and their usage of private ioctls. > module in it, you taint your kernel with "TAINT_CRAP" and you get a > message in your syslog saying that this driver isn't supported and you > might have problems. > > I have noted your objection to adding this driver to the Kconfig entry > for it. Thanks for that acknowledgment. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
