So, on my quest to suck up every out-of-tree driver and get it into the
main kernel tree (drivers/staging/ to start with), I've been pointed at
the rtl2860 driver.
Does anyone know of a "cleaned up" version of this driver that is
newer/better than the one on ralink's web site? I found the
2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
start with that if no one else has yet.
Any pointers are appreciated.
thanks,
greg "maintainer of crap" k-h
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
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? 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.
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.
Dan
[1] but obviously not very well or else we'd be putting effort where it
was needed!
On Tue, Oct 28, 2008 at 12:48 AM, Luis Correia <[email protected]> wrote:
> Hi!
>
> On Tue, Oct 28, 2008 at 07:03, Thorsten Leemhuis <[email protected]> wrote:
>> On 28.10.2008 01:49, Greg KH wrote:
>>>
>>> So, on my quest to suck up every out-of-tree driver and get it into the
>>> main kernel tree (drivers/staging/ to start with), I've been pointed at
>>> the rtl2860 driver.
>>
>> Does it really make sense to include a driver when a different one for
>> mainline inclusion is being actively developed? It might give some
>> developers the impression that it's worth spending time improving the
>> rtl2860/2870 drivers -- which might be wasted time in the end.
>
> Is it just me or you are suggesting we use the Ralink supplied driver,
> with its own wireless stack, rather then work with the rt2x00 team?
>
> Do we really want that again (several wireless stacks)?
Staging means temporary, a place for you to stash crap, which
ultimately and hopefully will unbecome crap and some sort of butterfly
will come out. Now I got poetic.
Luis
On Tue, Oct 28, 2008 at 1:12 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2008-10-28 at 01:02 -0700, Luis R. Rodriguez wrote:
>
>> > I don't think it makes sense either, at _best_ it'll do nothing but help
>> > a few users [1], and if somebody actually starts working on the vendor
>> > driver because it's in staging that's actively harmful to the real
>> > driver by diverting resources away from it.
>> >
>> > johannes
>> >
>> > [1] I used to think the point wasn't to make users happy but to make it
>> > easier to work on those drivers, but that objective seems long gone
>>
>> Problem is distributions already ship crap anyway.
>
> Well, yes, but that's fine, it doesn't mean people will work on the
> crap, it means people will use the crap. As far as I understood, putting
> it into staging was supposed to mean "here is some crap for people to
> work on", which is a huge difference.
Well its not staging if it doesn't work as well, if we are going to
stage might as well let it work while there are no alternatives no?
Luis
On Tue, Oct 28, 2008 at 7:59 AM, Dan Williams <[email protected]> wrote:
> On Mon, 2008-10-27 at 23:10 -0700, Greg KH wrote:
>> On Tue, Oct 28, 2008 at 06:48:31AM +0100, Ivo Van Doorn wrote:
>> > Hi,
>> >
>> > > So, on my quest to suck up every out-of-tree driver and get it into the
>> > > main kernel tree (drivers/staging/ to start with), I've been pointed at
>> > > the rtl2860 driver.
>> >
>> > in that case make sure you include rt2870 on your list as well then. ;)
>>
>> Do you have a pointer to it?
>>
>> > > Does anyone know of a "cleaned up" version of this driver that is
>> > > newer/better than the one on ralink's web site? I found the
>> > > 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
>> > > start with that if no one else has yet.
>> >
>> > rt2800pci/rt2800usb development is in progress in the rt2x00.git
>> > experimental branch:
>> > http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=shortlog;h=experimental
>> >
>> > The current status is that rt2800usb has working RX with some warnings
>> > regarding the
>> > RX signal, and a non functional TX. rt2800pci isn't complete yet.
>> >
>> > So far progress has been very slow because of lack of time, so any help with the
>> > development of the drivers is welcome.
>>
>> Is this a port of the tarball driver to the in-kernel wireless stack, or
>> starting over from scratch?
>>
>> As it's not really working, do you mind if I just dump the tarball
>> driver into the staging tree for users to use now (hint, they already
>> are, the distros are shipping that driver as a kernel module package),
>> and then when this "real" driver is up and working properly, we can drop
>> the staging version?
>
> Seriously, how does including this help _anybody_ beyond today?
In this particular case if Joe the Plumber installs Linux 6 months
from now chances are this move will get his Ralink 802.11n device
supported. Perhaps 6 months from now the rt2x00 driver port will be
ready though, in those cases people smarter than Joe the Plumber will
be able to use compat-wireless, lets say, or the latest -rc kernel
release to use an upstream driver which replaces it instead.
> The
> vendor driver is not going to get upstream,
Once in staging it means it is upstream now though.
> and shipping it in staging
> suggests that people help fix the vendor driver there,
It actually means developers have the option to work on what they
like, crap or not crap. And crap that works, or cool-stuff that
doesn't work quite well yet.
> not work on the
> driver that will actually go upstream.
It is not barring people who do want to work on the ubber cool
upstream driver from doing so; it *may* deviate effort of a few
developers -- this is true and this is what hurts. But like Johannes
says too, people spend tons of hours uselessly watching TV. So
technically it just gives developers and users more options. That is
all.
> staging drivers are supposed to eventually go "mainstream" if somebody
> fixes them up, right? So how does cramming in a driver that will go
> nowhere help anyone in the medium or long term?
Problem is having no support yet and that distributions still work on
getting the crap into their own distribution. Getting it into staging
should reduce the turnaround time for device to get supported.
> Should we have shipped
> madwifi with the open HAL in staging
They're not compatible though.
> while ath5k was getting brought up
> to speed?
If a real HAL did work I don't see why not if the premise is we are
willing to accept complete crap into staging.
> Would that have taken effort away from ath5k?
Yes but this cannot be avoided, despite my efforts people still want
to poke and maintain MadWifi. I have to respect that but it doesn't
mean my own resources or what I push for has to be dedicated towards
that.
> I highly respect the work that you're doing with staging, but just
> because the driver is out of tree doesn't mean that it'll ever go
> mainline, and that including some drivers will just sap effort from
> where it's needed.
This is the danger, and I wonder how much this is really true or
rather if this actually attracts more developers to keep crap working
for users willing to use crap in the meantime while other more
seasoned developers get stuff working *properly*.
> Cleaning up crappy vendor driver code is _not_ where
> the effort is needed. We have a higher standard of quality.
We do, but crap developers don't, and crap vendor developers don't either.
Should we have TAINT_CRAP ? :) Oh wait look!!!!
{ TAINT_CRAP, 'C', ' ' },
* 'C' - modules from drivers/staging are loaded.
>From panic.c! Yay!
Luis
Luis
Hi!
On Tue, Oct 28, 2008 at 07:03, Thorsten Leemhuis <[email protected]> wrote:
> On 28.10.2008 01:49, Greg KH wrote:
>>
>> So, on my quest to suck up every out-of-tree driver and get it into the
>> main kernel tree (drivers/staging/ to start with), I've been pointed at
>> the rtl2860 driver.
>
> Does it really make sense to include a driver when a different one for
> mainline inclusion is being actively developed? It might give some
> developers the impression that it's worth spending time improving the
> rtl2860/2870 drivers -- which might be wasted time in the end.
Is it just me or you are suggesting we use the Ralink supplied driver,
with its own wireless stack, rather then work with the rt2x00 team?
Do we really want that again (several wireless stacks)?
>> Does anyone know of a "cleaned up" version of this driver that is
>> newer/better than the one on ralink's web site? I found the
>> 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
>> start with that if no one else has yet.
>>
>> Any pointers are appreciated.
>
> You can find a few patches (needed for 2.6.26 and 2.6.27 iirc; not sure if
> they are enough to make it work on current mainline) for both rt2860 and
> rt2870 in CVS for RPM Fusion:
>
> http://cvs.rpmfusion.org/viewvc/rpms/rt2860-kmod/devel/?root=free
> http://cvs.rpmfusion.org/viewvc/rpms/rt2870-kmod/devel/?root=free
This seems to be only a set of 'mixed-up-lets-just-use-ralink-code' patchset.
>
> HTH
>
> CU
> knurd
p.s. I apologize in advance if I misunderstood the meaning of the
original reply.
Luis Correia
rt2x00 project admin
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.
johannes
On Tue, Oct 28, 2008 at 09:12:42AM +0100, Johannes Berg wrote:
> On Tue, 2008-10-28 at 01:02 -0700, Luis R. Rodriguez wrote:
>
> > > I don't think it makes sense either, at _best_ it'll do nothing but help
> > > a few users [1], and if somebody actually starts working on the vendor
> > > driver because it's in staging that's actively harmful to the real
> > > driver by diverting resources away from it.
> > >
> > > johannes
> > >
> > > [1] I used to think the point wasn't to make users happy but to make it
> > > easier to work on those drivers, but that objective seems long gone
> >
> > Problem is distributions already ship crap anyway.
>
> Well, yes, but that's fine, it doesn't mean people will work on the
> crap, it means people will use the crap. As far as I understood, putting
> it into staging was supposed to mean "here is some crap for people to
> work on", which is a huge difference.
"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?
thanks,
greg k-h
On 28.10.2008 01:49, Greg KH wrote:
> So, on my quest to suck up every out-of-tree driver and get it into the
> main kernel tree (drivers/staging/ to start with), I've been pointed at
> the rtl2860 driver.
Does it really make sense to include a driver when a different one for
mainline inclusion is being actively developed? It might give some
developers the impression that it's worth spending time improving the
rtl2860/2870 drivers -- which might be wasted time in the end.
> Does anyone know of a "cleaned up" version of this driver that is
> newer/better than the one on ralink's web site? I found the
> 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
> start with that if no one else has yet.
>
> Any pointers are appreciated.
You can find a few patches (needed for 2.6.26 and 2.6.27 iirc; not sure
if they are enough to make it work on current mainline) for both rt2860
and rt2870 in CVS for RPM Fusion:
http://cvs.rpmfusion.org/viewvc/rpms/rt2860-kmod/devel/?root=free
http://cvs.rpmfusion.org/viewvc/rpms/rt2870-kmod/devel/?root=free
HTH
CU
knurd
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
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.
It can be found at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-staging/staging-add-rtl2860-wireless-driver.patch
if anyone wants to review it before I send it to Linus.
thanks,
greg k-h
On Tue, 2008-10-28 at 01:02 -0700, Luis R. Rodriguez wrote:
> > I don't think it makes sense either, at _best_ it'll do nothing but help
> > a few users [1], and if somebody actually starts working on the vendor
> > driver because it's in staging that's actively harmful to the real
> > driver by diverting resources away from it.
> >
> > johannes
> >
> > [1] I used to think the point wasn't to make users happy but to make it
> > easier to work on those drivers, but that objective seems long gone
>
> Problem is distributions already ship crap anyway.
Well, yes, but that's fine, it doesn't mean people will work on the
crap, it means people will use the crap. As far as I understood, putting
it into staging was supposed to mean "here is some crap for people to
work on", which is a huge difference.
johannes
On Tue, 2008-10-28 at 08:03 +0100, Thorsten Leemhuis wrote:
> On 28.10.2008 01:49, Greg KH wrote:
> > So, on my quest to suck up every out-of-tree driver and get it into the
> > main kernel tree (drivers/staging/ to start with), I've been pointed at
> > the rtl2860 driver.
>
> Does it really make sense to include a driver when a different one for
> mainline inclusion is being actively developed? It might give some
> developers the impression that it's worth spending time improving the
> rtl2860/2870 drivers -- which might be wasted time in the end.
I don't think it makes sense either, at _best_ it'll do nothing but help
a few users [1], and if somebody actually starts working on the vendor
driver because it's in staging that's actively harmful to the real
driver by diverting resources away from it.
johannes
[1] I used to think the point wasn't to make users happy but to make it
easier to work on those drivers, but that objective seems long gone
Hi
On Tue, Oct 28, 2008 at 08:02, Luis R. Rodriguez <[email protected]> wrote:
> On Tue, Oct 28, 2008 at 12:56 AM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2008-10-28 at 08:03 +0100, Thorsten Leemhuis wrote:
>>> On 28.10.2008 01:49, Greg KH wrote:
>>> > So, on my quest to suck up every out-of-tree driver and get it into the
>>> > main kernel tree (drivers/staging/ to start with), I've been pointed at
>>> > the rtl2860 driver.
>>>
>>> Does it really make sense to include a driver when a different one for
>>> mainline inclusion is being actively developed? It might give some
>>> developers the impression that it's worth spending time improving the
>>> rtl2860/2870 drivers -- which might be wasted time in the end.
>>
>> I don't think it makes sense either, at _best_ it'll do nothing but help
>> a few users [1], and if somebody actually starts working on the vendor
>> driver because it's in staging that's actively harmful to the real
>> driver by diverting resources away from it.
>>
>> johannes
>>
>> [1] I used to think the point wasn't to make users happy but to make it
>> easier to work on those drivers, but that objective seems long gone
>
> Problem is distributions already ship crap anyway.
Exactly, last April I realised that Caixa Magica (the Portuguese
Mandriva spinoff) already had two drivers for Ralink chipsets, being
that it even had wrong usb ID's in the code. (a rtl8187 was identified
as rt72usb..)
>
> Luis
> --
Luis
On Mon, 2008-10-27 at 23:10 -0700, Greg KH wrote:
> On Tue, Oct 28, 2008 at 06:48:31AM +0100, Ivo Van Doorn wrote:
> > Hi,
> >
> > > So, on my quest to suck up every out-of-tree driver and get it into the
> > > main kernel tree (drivers/staging/ to start with), I've been pointed at
> > > the rtl2860 driver.
> >
> > in that case make sure you include rt2870 on your list as well then. ;)
>
> Do you have a pointer to it?
>
> > > Does anyone know of a "cleaned up" version of this driver that is
> > > newer/better than the one on ralink's web site? I found the
> > > 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
> > > start with that if no one else has yet.
> >
> > rt2800pci/rt2800usb development is in progress in the rt2x00.git
> > experimental branch:
> > http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=shortlog;h=experimental
> >
> > The current status is that rt2800usb has working RX with some warnings
> > regarding the
> > RX signal, and a non functional TX. rt2800pci isn't complete yet.
> >
> > So far progress has been very slow because of lack of time, so any help with the
> > development of the drivers is welcome.
>
> Is this a port of the tarball driver to the in-kernel wireless stack, or
> starting over from scratch?
>
> As it's not really working, do you mind if I just dump the tarball
> driver into the staging tree for users to use now (hint, they already
> are, the distros are shipping that driver as a kernel module package),
> and then when this "real" driver is up and working properly, we can drop
> the staging version?
Seriously, how does including this help _anybody_ beyond today? The
vendor driver is not going to get upstream, and shipping it in staging
suggests that people help fix the vendor driver there, not work on the
driver that will actually go upstream.
staging drivers are supposed to eventually go "mainstream" if somebody
fixes them up, right? So how does cramming in a driver that will go
nowhere help anyone in the medium or long term? Should we have shipped
madwifi with the open HAL in staging while ath5k was getting brought up
to speed? Would that have taken effort away from ath5k?
I highly respect the work that you're doing with staging, but just
because the driver is out of tree doesn't mean that it'll ever go
mainline, and that including some drivers will just sap effort from
where it's needed. Cleaning up crappy vendor driver code is _not_ where
the effort is needed. We have a higher standard of quality.
Dan
On 28.10.2008 08:48, Luis Correia wrote:
> On Tue, Oct 28, 2008 at 07:03, Thorsten Leemhuis <[email protected]> wrote:
>> On 28.10.2008 01:49, Greg KH wrote:
>>> So, on my quest to suck up every out-of-tree driver and get it into the
>>> main kernel tree (drivers/staging/ to start with), I've been pointed at
>>> the rtl2860 driver.
>> Does it really make sense to include a driver when a different one for
>> mainline inclusion is being actively developed? It might give some
>> developers the impression that it's worth spending time improving the
>> rtl2860/2870 drivers -- which might be wasted time in the end.
>
> Is it just me or you are suggesting we use the Ralink supplied driver,
> with its own wireless stack, rather then work with the rt2x00 team?
No, I'm definitely not suggesting that! In fact it's the other way
around: I wondering if it's more harm- than helpful to include the
current Ralink supplied driver as staging driver.
Or, to say it more directly: I think the Ralink drivers should not get
included as staging driver, as that might track away resources from the
rt2x00 effort (just my 2 cent as LKML and linux-wlan lurker of course).
> [...]
>>> Does anyone know of a "cleaned up" version of this driver that is
>>> newer/better than the one on ralink's web site? I found the
>>> 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
>>> start with that if no one else has yet.
>>>
>>> Any pointers are appreciated.
>> You can find a few patches (needed for 2.6.26 and 2.6.27 iirc; not sure if
>> they are enough to make it work on current mainline) for both rt2860 and
>> rt2870 in CVS for RPM Fusion:
>>
>> http://cvs.rpmfusion.org/viewvc/rpms/rt2860-kmod/devel/?root=free
>> http://cvs.rpmfusion.org/viewvc/rpms/rt2870-kmod/devel/?root=free
>
> This seems to be only a set of 'mixed-up-lets-just-use-ralink-code' patchset.
Sure -- nevertheless those patches might be helpful for Greg, that's why
I pointed him there.
BTW, RPM Fusion provides the drivers just as a interim solution for
Fedora users, as there was quite some demand for it (even from one well
known kernel developer who actually created the initial rt2860 package
for Livna/RPM Fusion); soon after a working and stable driver with a
similar featureset is in mainline and shipped as update by Fedora we'll
stop providing those drivers from Ralink.
> p.s. I apologize in advance if I misunderstood the meaning of the
> original reply.
np ;-)
CU
knurd
>> > So, on my quest to suck up every out-of-tree driver and get it into the
>> > main kernel tree (drivers/staging/ to start with), I've been pointed at
>> > the rtl2860 driver.
>>
>> in that case make sure you include rt2870 on your list as well then. ;)
>
> Do you have a pointer to it?
http://www.ralinktech.com.tw/data/drivers/2008_0925_RT2870_Linux_STA_v1.4.0.0.tar.bz2
But as mentioned the rt2800usb is underway.
>> > Does anyone know of a "cleaned up" version of this driver that is
>> > newer/better than the one on ralink's web site? I found the
>> > 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
>> > start with that if no one else has yet.
>>
>> rt2800pci/rt2800usb development is in progress in the rt2x00.git
>> experimental branch:
>> http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=shortlog;h=experimental
>>
>> The current status is that rt2800usb has working RX with some warnings
>> regarding the
>> RX signal, and a non functional TX. rt2800pci isn't complete yet.
>>
>> So far progress has been very slow because of lack of time, so any help with the
>> development of the drivers is welcome.
>
> Is this a port of the tarball driver to the in-kernel wireless stack, or
> starting over from scratch?
Starting from scratch, well actually hooking it into the rt2x00lib library,
so only the real register initializations are being copied. ;)
> As it's not really working, do you mind if I just dump the tarball
> driver into the staging tree for users to use now (hint, they already
> are, the distros are shipping that driver as a kernel module package),
> and then when this "real" driver is up and working properly, we can drop
> the staging version?
No objections, but who is going to provide support for them and maintain them
to make sure they compile?
I am already stretched in time, and I have absolutely no interest in maintaining
or supporting those old drivers. I understood there were quite a lot
of problems with
the drivers, so putting them in an "official" tree might lead to a
large series of
support requests.
Ivo
On Tue, Oct 28, 2008 at 06:48:31AM +0100, Ivo Van Doorn wrote:
> Hi,
>
> > So, on my quest to suck up every out-of-tree driver and get it into the
> > main kernel tree (drivers/staging/ to start with), I've been pointed at
> > the rtl2860 driver.
>
> in that case make sure you include rt2870 on your list as well then. ;)
Do you have a pointer to it?
> > Does anyone know of a "cleaned up" version of this driver that is
> > newer/better than the one on ralink's web site? I found the
> > 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
> > start with that if no one else has yet.
>
> rt2800pci/rt2800usb development is in progress in the rt2x00.git
> experimental branch:
> http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=shortlog;h=experimental
>
> The current status is that rt2800usb has working RX with some warnings
> regarding the
> RX signal, and a non functional TX. rt2800pci isn't complete yet.
>
> So far progress has been very slow because of lack of time, so any help with the
> development of the drivers is welcome.
Is this a port of the tarball driver to the in-kernel wireless stack, or
starting over from scratch?
As it's not really working, do you mind if I just dump the tarball
driver into the staging tree for users to use now (hint, they already
are, the distros are shipping that driver as a kernel module package),
and then when this "real" driver is up and working properly, we can drop
the staging version?
thanks,
greg k-h
On Tue, 2008-10-28 at 01:17 -0700, Luis R. Rodriguez wrote:
> >> Problem is distributions already ship crap anyway.
> >
> > Well, yes, but that's fine, it doesn't mean people will work on the
> > crap, it means people will use the crap. As far as I understood, putting
> > it into staging was supposed to mean "here is some crap for people to
> > work on", which is a huge difference.
>
> Well its not staging if it doesn't work as well, if we are going to
> stage might as well let it work while there are no alternatives no?
They can always use the distro shipped crap and hack on the real driver.
johannes
On Tue, Oct 28, 2008 at 08:06:39AM +0000, Luis Correia wrote:
> Hi
>
> On Tue, Oct 28, 2008 at 08:02, Luis R. Rodriguez <[email protected]> wrote:
> > On Tue, Oct 28, 2008 at 12:56 AM, Johannes Berg
> > <[email protected]> wrote:
> >> On Tue, 2008-10-28 at 08:03 +0100, Thorsten Leemhuis wrote:
> >>> On 28.10.2008 01:49, Greg KH wrote:
> >>> > So, on my quest to suck up every out-of-tree driver and get it into the
> >>> > main kernel tree (drivers/staging/ to start with), I've been pointed at
> >>> > the rtl2860 driver.
> >>>
> >>> Does it really make sense to include a driver when a different one for
> >>> mainline inclusion is being actively developed? It might give some
> >>> developers the impression that it's worth spending time improving the
> >>> rtl2860/2870 drivers -- which might be wasted time in the end.
> >>
> >> I don't think it makes sense either, at _best_ it'll do nothing but help
> >> a few users [1], and if somebody actually starts working on the vendor
> >> driver because it's in staging that's actively harmful to the real
> >> driver by diverting resources away from it.
> >>
> >> johannes
> >>
> >> [1] I used to think the point wasn't to make users happy but to make it
> >> easier to work on those drivers, but that objective seems long gone
> >
> > Problem is distributions already ship crap anyway.
>
> Exactly, last April I realised that Caixa Magica (the Portuguese
> Mandriva spinoff) already had two drivers for Ralink chipsets, being
> that it even had wrong usb ID's in the code. (a rtl8187 was identified
> as rt72usb..)
It is this kind of problem that I am trying to address here. If these
drivers are in the kernel, then this stuff can easily be fixed, so the
distros can't get it wrong (well, it will take some effort on their part
to get it wrong...)
thanks,
greg k-h
On Tue, Oct 28, 2008 at 07:48:54AM +0000, Luis Correia wrote:
> Hi!
>
> On Tue, Oct 28, 2008 at 07:03, Thorsten Leemhuis <[email protected]> wrote:
> > On 28.10.2008 01:49, Greg KH wrote:
> >>
> >> So, on my quest to suck up every out-of-tree driver and get it into the
> >> main kernel tree (drivers/staging/ to start with), I've been pointed at
> >> the rtl2860 driver.
> >
> > Does it really make sense to include a driver when a different one for
> > mainline inclusion is being actively developed? It might give some
> > developers the impression that it's worth spending time improving the
> > rtl2860/2870 drivers -- which might be wasted time in the end.
>
> Is it just me or you are suggesting we use the Ralink supplied driver,
> with its own wireless stack, rather then work with the rt2x00 team?
No, See my other post in this thread about what I am suggesting.
> Do we really want that again (several wireless stacks)?
We already have that in the "crap" tree today (see drivers/staging/) :)
thanks,
greg k-h
Hi,
> So, on my quest to suck up every out-of-tree driver and get it into the
> main kernel tree (drivers/staging/ to start with), I've been pointed at
> the rtl2860 driver.
in that case make sure you include rt2870 on your list as well then. ;)
> Does anyone know of a "cleaned up" version of this driver that is
> newer/better than the one on ralink's web site? I found the
> 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
> start with that if no one else has yet.
rt2800pci/rt2800usb development is in progress in the rt2x00.git
experimental branch:
http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=shortlog;h=experimental
The current status is that rt2800usb has working RX with some warnings
regarding the
RX signal, and a non functional TX. rt2800pci isn't complete yet.
So far progress has been very slow because of lack of time, so any help with the
development of the drivers is welcome.
Ivo
On Tue, Oct 28, 2008 at 12:56 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2008-10-28 at 08:03 +0100, Thorsten Leemhuis wrote:
>> On 28.10.2008 01:49, Greg KH wrote:
>> > So, on my quest to suck up every out-of-tree driver and get it into the
>> > main kernel tree (drivers/staging/ to start with), I've been pointed at
>> > the rtl2860 driver.
>>
>> Does it really make sense to include a driver when a different one for
>> mainline inclusion is being actively developed? It might give some
>> developers the impression that it's worth spending time improving the
>> rtl2860/2870 drivers -- which might be wasted time in the end.
>
> I don't think it makes sense either, at _best_ it'll do nothing but help
> a few users [1], and if somebody actually starts working on the vendor
> driver because it's in staging that's actively harmful to the real
> driver by diverting resources away from it.
>
> johannes
>
> [1] I used to think the point wasn't to make users happy but to make it
> easier to work on those drivers, but that objective seems long gone
Problem is distributions already ship crap anyway.
Luis