linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).