Message-Id: <200907301517.57811.bzolnier@gmail.com>
Date:	Thu, 30 Jul 2009 15:17:54 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Luis Correia <luis.f.correia@...il.com>
Cc:	Mike Galbraith <efault@....de>, linux-wireless@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today


Hi,

On Thursday 30 July 2009 12:06:00 Luis Correia wrote:
> Hi Mike,
> 
> On Thu, Jul 30, 2009 at 10:55, Johannes Berg<johannes@...solutions.net> wrote:
> > On Thu, 2009-07-30 at 11:44 +0200, Mike Galbraith wrote:
> >> On Thu, 2009-07-30 at 11:29 +0200, Johannes Berg wrote:
> >> > On Thu, 2009-07-30 at 11:22 +0200, Mike Galbraith wrote:
> >> >
> >> > > drivers/staging/rt2870/../rt2860/sta_ioctl.c
> >> >
> >> > Sorry, but that '/staging/' thing in there means we cannot support this.
> >> > If you must, take your query to the staging list,
> >> > devel@...verdev.osuosl.org (according to MAINTAINERS).
> >>
> >> Forwarded, thanks.
> >>
> >> ....hm.  Does "If you must" mean reports aren't welcome?
> >
> > To be honest, I don't know. I'd rather see people use the rt2x00 code
> > instead of spending time cleaning up that mess (the code you've pasted
> > was pretty bad!). But you may or may not find somebody who cares about
> > that, just rather unlikely on this list.

rt2800pci which I would need for my Asus Eee 901 is not even ready for
the upstream inclusion (after a year or so since Ralink's driver has been
released).

The sad reality is that some vendors have discovered "the loophole" in
the current kernel development model and are using it.  Pretending that
the GPL-ed-but-fugly _working_ drivers do not exist is not an answer!

[ Especially not in the long-term (I think thank the support for the newest
  generation of Ralink chipsets will probably also be based on more-or-less
  the same code base). ]

Users are pragmatic beasts and don't care about "proper" code.  They are
just using what works "good enough" for them (i.e. if distribution ships
a slightly inferior solution to the official one nobody will bother with
the official one, now lets think about the incomplete official one..).

No, I don't have a good answer for the problem.  However I think that we
should be looking for the real, long-term solution instead of pretending
that the issue doesn't exist.

> What is appreciated is people with time to compare both code paths,
> and report some inconsistancies, specially about card initialization
> and general handling.

You are talking about people who:
* are familiar with wireless networking and wireless drivers
* have ability to work with the ugly/complicated code
* have good code reading/review skills
* have a quite some free time in their hands

Well, good luck..

> To be hones, we, the rt2x00 team, find Ralink's code to be very
> difficult to follow, and combersome most of the times.

I completely agree but it _works_, rt2x00 does _not_.

> But any help is welcome!

I think that cleaning of vendor drivers is an indirect form of help to
rt2x00 team (by making the mess easier to read and comprehend) and not a
competition to rt2x00 project.  rt2x00 code is of very high quality and
I'm impressed by the work done by you, Ivo and the rest of the team.
However I think that you will never able to out do the _vendor_ when it
comes to the support for their new devices and I find the idea of finding
highly skilled volunteers helping with the most difficult, tedious and
thankless parts of the work a bit over-optimistic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists