From: Greg KH <greg@kroah.com>
To: Dan Williams <dcbw@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
"Luis R. Rodriguez" <mcgrof@gmail.com>,
Thorsten Leemhuis <fedora@leemhuis.info>,
rt2400-devel@lists.sourceforge.net,
linux-wireless@vger.kernel.org
Subject: Re: rtl2860 driver in mainline?
Date: Wed, 29 Oct 2008 09:30:27 -0700 [thread overview]
Message-ID: <20081029163027.GA20440@kroah.com> (raw)
In-Reply-To: <1225275184.28968.13.camel@localhost.localdomain>
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?
That's sad.
> 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
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,
greg k-h
next prev parent reply other threads:[~2008-10-29 16:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 0:49 rtl2860 driver in mainline? Greg KH
2008-10-28 5:48 ` Ivo Van Doorn
2008-10-28 6:10 ` Greg KH
2008-10-28 6:23 ` Ivo Van Doorn
2008-10-28 14:59 ` Dan Williams
2008-10-28 17:24 ` Luis R. Rodriguez
2008-10-28 7:03 ` Thorsten Leemhuis
2008-10-28 7:48 ` Luis Correia
2008-10-28 8:01 ` Luis R. Rodriguez
2008-10-28 8:06 ` Thorsten Leemhuis
2008-10-28 17:10 ` Greg KH
2008-10-28 7:56 ` Johannes Berg
2008-10-28 8:02 ` Luis R. Rodriguez
2008-10-28 8:06 ` Luis Correia
2008-10-28 17:09 ` Greg KH
2008-10-28 8:12 ` Johannes Berg
2008-10-28 8:17 ` Luis R. Rodriguez
2008-10-28 8:19 ` Johannes Berg
2008-10-28 17:08 ` Greg KH
2008-10-28 18:35 ` Johannes Berg
2008-10-28 22:45 ` Greg KH
2008-10-29 10:13 ` Dan Williams
2008-10-29 16:30 ` Greg KH [this message]
2008-10-30 4:02 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081029163027.GA20440@kroah.com \
--to=greg@kroah.com \
--cc=dcbw@redhat.com \
--cc=fedora@leemhuis.info \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.com \
--cc=rt2400-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.