11:58 p.m.
I know this is a staging and thus experimental driver.
I only wanted to point out that if you compile the kernl
without SMP support, then this driver module will have these
undefined symbols:
spin_lock_bh
_per_cpu_offset
synchronize_irq
spin_unlock_irqrestore
del_timer_sync
spin_lock_irqsave
I did a cursory look at part of the code, and it is obvious
this code is not up to snuff in coding style, and in one file, missing
header include.
At the very least, the code needs to surround locking
and unlocking code with
#ifdef CONFIG_SMP
spin_lock... or spin_unlock ...
#endif
My $.02's worth
Cheers,
Markus K.
_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_M...
1:17 a.m.
On Wednesday 05 August 2009 09:58:44 pm Markus Kesaromous wrote:
I know this is a staging and thus experimental driver.
I only wanted to point out that if you compile the kernl
without SMP support, then this driver module will have these
undefined symbols:
Which Fedora kernels are compiled without SMP support?
Regards,
--
Conrad Meyer <cemeyer(a)u.washington.edu>
1:48 a.m.
----------------------------------------
From: cemeyer(a)u.washington.edu
To: fedora-devel-list(a)redhat.com
Date: Wed, 5 Aug 2009 23:17:12 -0700
Subject: Re: rt2860 driver (fc11)
On Wednesday 05 August 2009 09:58:44 pm Markus Kesaromous wrote:
> I know this is a staging and thus experimental driver.
> I only wanted to point out that if you compile the kernl
> without SMP support, then this driver module will have these
> undefined symbols:
Which Fedora kernels are compiled without SMP support?
Regards,
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I compiled the kernel without SMP support deliberately.
It is a user configurable option.
_________________________________________________________________
Get your vacation photos on your phone!
http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809T...
2:20 a.m.
On Wednesday 05 August 2009 11:48:05 pm Markus Kesaromous wrote:
I compiled the kernel without SMP support deliberately.
It is a user configurable option.
If you're not using a Fedora kernel the appropriate place to complain /
discuss is the LKML, not here. Even if it was a Fedora kernel, the place for
this is fedora-kernel-list.
Regards,
--
Conrad Meyer <cemeyer(a)u.washington.edu>
1:27 a.m.
On Wed, 2009-08-05 at 21:58 -0700, Markus Kesaromous wrote:
I know this is a staging and thus experimental driver.
I only wanted to point out that if you compile the kernl
without SMP support, then this driver module will have these
undefined symbols:
spin_lock_bh
_per_cpu_offset
synchronize_irq
spin_unlock_irqrestore
del_timer_sync
spin_lock_irqsave
I did a cursory look at part of the code, and it is obvious
this code is not up to snuff in coding style, and in one file, missing
header include.
At the very least, the code needs to surround locking
and unlocking code with
#ifdef CONFIG_SMP
spin_lock... or spin_unlock ...
#endif
Wouldn't this be better sent to lkml? I don't think anyone in Fedora
works on the in-kernel rt2860 driver, do they? I don't recognize any of
the names in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=histor...
as being 'Fedora people'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:50 a.m.
----------------------------------------
From: awilliam(a)redhat.com
To: fedora-devel-list(a)redhat.com
Date: Wed, 5 Aug 2009 23:27:32 -0700
Subject: Re: rt2860 driver (fc11)
On Wed, 2009-08-05 at 21:58 -0700, Markus Kesaromous wrote:
> I know this is a staging and thus experimental driver.
> I only wanted to point out that if you compile the kernl
> without SMP support, then this driver module will have these
> undefined symbols:
>
> spin_lock_bh
> _per_cpu_offset
> synchronize_irq
> spin_unlock_irqrestore
> del_timer_sync
> spin_lock_irqsave
>
> I did a cursory look at part of the code, and it is obvious
> this code is not up to snuff in coding style, and in one file, missing
> header include.
> At the very least, the code needs to surround locking
> and unlocking code with
> #ifdef CONFIG_SMP
> spin_lock... or spin_unlock ...
> #endif
Wouldn't this be better sent to lkml? I don't think anyone in Fedora
works on the in-kernel rt2860 driver, do they? I don't recognize any of
the names in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=histor...
as being 'Fedora people'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I was hoping that the devs who worked hard to even make it part of the source rpm might be
lurking on this mailing list and see my post :)
_________________________________________________________________
Express your personality in color! Preview and select themes for Hotmail®.
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID233...
2:12 a.m.
On Wed, 2009-08-05 at 23:50 -0700, Markus Kesaromous wrote:
I was hoping that the devs who worked hard to even make it part of
the source rpm might be lurking on this mailing list and see my post :)
I don't think anything special is done to make it part of our
kernel .src.rpm, it's just in there because it's in the upstream kernel
tarball :). I don't _think_ any of the Fedora kernel devs will jump to
fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based
card and it'd be nice not to have to rely on an out-of-tree,
not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or
one of the main committers directly, though.
Actually, now I look at it, it appears the driver is developed as part
of the serialmonkey project:
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which has links in the blue bar at the top for 'lists' and 'forum'.
Those sound like good places to poke.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:57 a.m.
On Thu, Aug 6, 2009 at 9:12 AM, Adam Williamson<awilliam(a)redhat.com> wrote:
On Wed, 2009-08-05 at 23:50 -0700, Markus Kesaromous wrote:
> I was hoping that the devs who worked hard to even make it part of the source rpm
might be lurking on this mailing list and see my post :)
I don't think anything special is done to make it part of our
kernel .src.rpm, it's just in there because it's in the upstream kernel
tarball :). I don't _think_ any of the Fedora kernel devs will jump to
fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based
card and it'd be nice not to have to rely on an out-of-tree,
not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or
one of the main committers directly, though.
Actually, now I look at it, it appears the driver is developed as part
of the serialmonkey project:
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which has links in the blue bar at the top for 'lists' and 'forum'.
Those sound like good places to poke.
The rt2860 driver is the Vendor driver provided by Ralink, it is
considered crap by linux-wireless developers (for good reasons).
Upstream work is being done on rt2800pci / rt2800usb the usb driver is
supposed to be in a working state right now, the pci one could need
some help (its not there yet).
3:23 a.m.
> I was hoping that the devs who worked hard to even make it part
of the source rpm might be lurking on this mailing list and see my post :)
I don't think anything special is done to make it part of our
kernel .src.rpm, it's just in there because it's in the upstream kernel
tarball :). I don't _think_ any of the Fedora kernel devs will jump to
fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based
card and it'd be nice not to have to rely on an out-of-tree,
not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or
one of the main committers directly, though.
Actually, now I look at it, it appears the driver is developed as part
of the serialmonkey project:
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which has links in the blue bar at the top for 'lists' and 'forum'.
Those sound like good places to poke.
Good luck with that! This driver has been in the process of being
re-written for well over a year, I've long given up hope. Its
unfortunate as its in alot of netbooks including all the atom based
eeePCs. Fortunately rpmfusion has one that works reasonably well (it
even suspends and resumes!) appart from spewing massive amount of
debug into /var/log/messages (if left on about half a gig a day).
Peter
3:45 a.m.
On Thu, Aug 6, 2009 at 4:23 AM, Peter Robinson wrote:
>> I was hoping that the devs who worked hard to even make it
part of the source rpm might be lurking on this mailing list and see my post :)
>
> I don't think anything special is done to make it part of our
> kernel .src.rpm, it's just in there because it's in the upstream kernel
> tarball :). I don't _think_ any of the Fedora kernel devs will jump to
> fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based
> card and it'd be nice not to have to rely on an out-of-tree,
> not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or
> one of the main committers directly, though.
>
> Actually, now I look at it, it appears the driver is developed as part
> of the serialmonkey project:
>
> http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
>
> which has links in the blue bar at the top for 'lists' and 'forum'.
> Those sound like good places to poke.
Good luck with that! This driver has been in the process of being
re-written for well over a year, I've long given up hope. Its
unfortunate as its in alot of netbooks including all the atom based
eeePCs. Fortunately rpmfusion has one that works reasonably well (it
even suspends and resumes!) appart from spewing massive amount of
debug into /var/log/messages (if left on about half a gig a day).
Peter
I maintain those drivers at RPMFusion. I will be happy beyond
imagination when the staging drivers are marked stable. It would save
me a lot of work, for it's not just rt2860, but also rt2870 and
rt3070. I keep writing patches and hacks to them for almost every
kernel update since Ralink is a bit slow with kernel updates. I'm glad
they are working though :)
Orcan
3:58 a.m.
On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil<oget.fedora(a)gmail.com> wrote:
On Thu, Aug 6, 2009 at 4:23 AM, Peter Robinson wrote:
>>> I was hoping that the devs who worked hard to even make it part of the source
rpm might be lurking on this mailing list and see my post :)
>>
>> I don't think anything special is done to make it part of our
>> kernel .src.rpm, it's just in there because it's in the upstream kernel
>> tarball :). I don't _think_ any of the Fedora kernel devs will jump to
>> fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based
>> card and it'd be nice not to have to rely on an out-of-tree,
>> not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or
>> one of the main committers directly, though.
>>
>> Actually, now I look at it, it appears the driver is developed as part
>> of the serialmonkey project:
>>
>> http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
>>
>> which has links in the blue bar at the top for 'lists' and
'forum'.
>> Those sound like good places to poke.
>
> Good luck with that! This driver has been in the process of being
> re-written for well over a year, I've long given up hope. Its
> unfortunate as its in alot of netbooks including all the atom based
> eeePCs. Fortunately rpmfusion has one that works reasonably well (it
> even suspends and resumes!) appart from spewing massive amount of
> debug into /var/log/messages (if left on about half a gig a day).
>
> Peter
>
I maintain those drivers at RPMFusion. I will be happy beyond
imagination when the staging drivers are marked stable.
They won't ever (the rtxxxx Vendor drivers)
4:14 a.m.
On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote:
On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote:
>
> I maintain those drivers at RPMFusion. I will be happy beyond
> imagination when the staging drivers are marked stable.
They won't ever (the rtxxxx Vendor drivers)
From my understanding, the staging tree of the kernel contains drivers
that are being prepared to be included in the main kernel tree[1].
Correct me if I'm wrong.
I'm not quite sure if I could catch what you meant. Are you being
sarcastic, implying that the rt2xxx staging drivers will stay in the
staging repo forever? I sure hope not :) Hey! Don't break my hopes!
Orcan
[1] http://lwn.net/Articles/285594/
4:17 a.m.
On 08/06/2009 02:44 PM, Orcan Ogetbil wrote:
On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote:
> On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote:
>>
>> I maintain those drivers at RPMFusion. I will be happy beyond
>> imagination when the staging drivers are marked stable.
>
> They won't ever (the rtxxxx Vendor drivers)
>
>From my understanding, the staging tree of the kernel contains drivers
that are being prepared to be included in the main kernel tree[1].
Correct me if I'm wrong.
That is the general intention but not all drivers will pass through
however. Some of them are getting replaced with alternative drivers and
that happens to be the case for the ones you have packaged.
Rahul
4:34 a.m.
On Thu, Aug 6, 2009 at 11:14 AM, Orcan Ogetbil<oget.fedora(a)gmail.com> wrote:
On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote:
> On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote:
>>
>> I maintain those drivers at RPMFusion. I will be happy beyond
>> imagination when the staging drivers are marked stable.
>
> They won't ever (the rtxxxx Vendor drivers)
>
>From my understanding, the staging tree of the kernel contains drivers
that are being prepared to be included in the main kernel tree[1].
Correct me if I'm wrong.
I'm not quite sure if I could catch what you meant. Are you being
sarcastic, implying that the rt2xxx staging drivers will stay in the
staging repo forever? I sure hope not :) Hey! Don't break my hopes!
The rtxxxx vendor drivers are considered a dead end by the
linux-wireless developers (just try to read the code and you would now
why), the plan is to get rt2800pci and rt2800usb into shape and get
them upstreamed.
They get no support from the wireless developers at all, Greg added
them to staging because "they are better than no drivers".
See the linux-wireless list for details.
5:59 a.m.
On 06.08.2009 11:34, drago01 wrote:
On Thu, Aug 6, 2009 at 11:14 AM, Orcan
Ogetbil<oget.fedora(a)gmail.com> wrote:
> On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote:
>> On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote:
>>> I maintain those drivers at RPMFusion. I will be happy beyond
>>> imagination when the staging drivers are marked stable.
>> They won't ever (the rtxxxx Vendor drivers)
> >From my understanding, the staging tree of the kernel contains drivers
> that are being prepared to be included in the main kernel tree[1].
> Correct me if I'm wrong.
> I'm not quite sure if I could catch what you meant. Are you being
> sarcastic, implying that the rt2xxx staging drivers will stay in the
> staging repo forever? I sure hope not :) Hey! Don't break my hopes!
The rtxxxx vendor drivers are considered a dead end by the
linux-wireless developers (just try to read the code and you would now
why), the plan is to get rt2800pci and rt2800usb into shape and get
them upstreamed.
They get no support from the wireless developers at all, Greg added
them to staging because "they are better than no drivers".
See the linux-wireless list for details.
A small "just for your information" in addition to what drago said
(which is all afaics correct):
Some rough support for newrt ralink usb devices was added for 2.6.31; see
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
for details like this commit-comment:
"""
Current problems:
* Cannot scan 11n AP's
* No TX during first minute after association
* Broken Hardware encryption
"""
CU
knurd
12:27 p.m.
On Thu, 2009-08-06 at 11:34 +0200, drago01 wrote:
> I'm not quite sure if I could catch what you meant. Are you
being
> sarcastic, implying that the rt2xxx staging drivers will stay in the
> staging repo forever? I sure hope not :) Hey! Don't break my hopes!
The rtxxxx vendor drivers are considered a dead end by the
linux-wireless developers (just try to read the code and you would now
why), the plan is to get rt2800pci and rt2800usb into shape and get
them upstreamed.
They get no support from the wireless developers at all, Greg added
them to staging because "they are better than no drivers".
Thanks for the clarification. From what I read, I inferred that the
driver in /staging was the serialmonkey driver, but it seems I read it
wrong, and what it actually means to say was 'this is the vendor driver,
it sucks, don't contribute any code to this driver, contribute to the
serialmonkey driver instead'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:43 p.m.
On Thu, Aug 6, 2009 at 1:27 PM, Adam Williamson wrote:
On Thu, 2009-08-06 at 11:34 +0200, drago01 wrote:
> > I'm not quite sure if I could catch what you meant. Are you being
> > sarcastic, implying that the rt2xxx staging drivers will stay in the
> > staging repo forever? I sure hope not :) Hey! Don't break my hopes!
>
> The rtxxxx vendor drivers are considered a dead end by the
> linux-wireless developers (just try to read the code and you would now
> why), the plan is to get rt2800pci and rt2800usb into shape and get
> them upstreamed.
>
> They get no support from the wireless developers at all, Greg added
> them to staging because "they are better than no drivers".
Thanks for the clarification. From what I read, I inferred that the
driver in /staging was the serialmonkey driver, but it seems I read it
wrong, and what it actually means to say was 'this is the vendor driver,
it sucks, don't contribute any code to this driver, contribute to the
serialmonkey driver instead'.
I had the same confusion. So there are 3 drivers around: The vendor
driver, the staging driver which is a fork of the vendor driver and
the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and
rt3070. And this leads to another confusion. Do (or will) the Fedora
kernels have these staging drivers compiled by default? If that's the
case and if the staging driver is as stable as the original vendor
driver, I won't have to maintain those kmods anymore.
Orcan
1:52 p.m.
> Thanks for the clarification. From what I read, I inferred that
the
> driver in /staging was the serialmonkey driver, but it seems I read it
> wrong, and what it actually means to say was 'this is the vendor driver,
> it sucks, don't contribute any code to this driver, contribute to the
> serialmonkey driver instead'.
>
I had the same confusion. So there are 3 drivers around: The vendor
driver, the staging driver which is a fork of the vendor driver and
the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and
rt3070. And this leads to another confusion. Do (or will) the Fedora
kernels have these staging drivers compiled by default? If that's the
case and if the staging driver is as stable as the original vendor
driver, I won't have to maintain those kmods anymore.
The fedora kernel developers have always stated that the
staging/vendor drivers will never get enabled. Only once the other
ones are ready will they be turned on.
Peter
2:01 p.m.
On Thu, Aug 06, 2009 at 07:52:43PM +0100, Peter Robinson wrote:
>> Thanks for the clarification. From what I read, I inferred
that the
>> driver in /staging was the serialmonkey driver, but it seems I read it
>> wrong, and what it actually means to say was 'this is the vendor driver,
>> it sucks, don't contribute any code to this driver, contribute to the
>> serialmonkey driver instead'.
>>
>
> I had the same confusion. So there are 3 drivers around: The vendor
> driver, the staging driver which is a fork of the vendor driver and
> the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and
> rt3070. And this leads to another confusion. Do (or will) the Fedora
> kernels have these staging drivers compiled by default? If that's the
> case and if the staging driver is as stable as the original vendor
> driver, I won't have to maintain those kmods anymore.
The fedora kernel developers have always stated that the
staging/vendor drivers will never get enabled. Only once the other
ones are ready will they be turned on.
No we haven't, we've stated that they'll be enabled if someone steps up
to the plate to make an active contribution to maintenance and
improvements.
https://fedoraproject.org/wiki/KernelStagingPolicy
regards, Kyle
2:15 p.m.
> > I had the same confusion. So there are 3 drivers around: The
vendor
> > driver, the staging driver which is a fork of the vendor driver and
> > the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and
> > rt3070. And this leads to another confusion. Do (or will) the Fedora
> > kernels have these staging drivers compiled by default? If that's the
> > case and if the staging driver is as stable as the original vendor
> > driver, I won't have to maintain those kmods anymore.
>
> The fedora kernel developers have always stated that the
> staging/vendor drivers will never get enabled. Only once the other
> ones are ready will they be turned on.
>
No we haven't, we've stated that they'll be enabled if someone steps up
to the plate to make an active contribution to maintenance and
improvements.
https://fedoraproject.org/wiki/KernelStagingPolicy
Sorry, hadn't seen that. Was basing it on the comment in this bug
https://bugzilla.redhat.com/show_bug.cgi?id=463111
Peter
2:20 p.m.
On Thu, Aug 06, 2009 at 08:15:59PM +0100, Peter Robinson wrote:
>> > I had the same confusion. So there are 3 drivers
around: The vendor
>> > driver, the staging driver which is a fork of the vendor driver and
>> > the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and
>> > rt3070. And this leads to another confusion. Do (or will) the Fedora
>> > kernels have these staging drivers compiled by default? If that's the
>> > case and if the staging driver is as stable as the original vendor
>> > driver, I won't have to maintain those kmods anymore.
>>
>> The fedora kernel developers have always stated that the
>> staging/vendor drivers will never get enabled. Only once the other
>> ones are ready will they be turned on.
>>
>
> No we haven't, we've stated that they'll be enabled if someone steps up
> to the plate to make an active contribution to maintenance and
> improvements.
>
> https://fedoraproject.org/wiki/KernelStagingPolicy
Sorry, hadn't seen that. Was basing it on the comment in this bug
https://bugzilla.redhat.com/show_bug.cgi?id=463111
Yeah, the wireless drivers are "special" since the vendor drivers, as
stated elsewhere, usually supply their own entire 802.11 stack and other
ugliness. I don't want to speak for John, but I suspect if someone
stepped up to maintain a staging wireless driver in the interim, he
wouldn't object.
regards, Kyle
4:10 p.m.
On Thu, 2009-08-06 at 15:20 -0400, Kyle McMartin wrote:
On Thu, Aug 06, 2009 at 08:15:59PM +0100, Peter Robinson wrote:
> >> > I had the same confusion. So there are 3 drivers around: The vendor
> >> > driver, the staging driver which is a fork of the vendor driver and
> >> > the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and
> >> > rt3070. And this leads to another confusion. Do (or will) the Fedora
> >> > kernels have these staging drivers compiled by default? If that's
the
> >> > case and if the staging driver is as stable as the original vendor
> >> > driver, I won't have to maintain those kmods anymore.
> >>
> >> The fedora kernel developers have always stated that the
> >> staging/vendor drivers will never get enabled. Only once the other
> >> ones are ready will they be turned on.
> >>
> >
> > No we haven't, we've stated that they'll be enabled if someone
steps up
> > to the plate to make an active contribution to maintenance and
> > improvements.
> >
> > https://fedoraproject.org/wiki/KernelStagingPolicy
>
> Sorry, hadn't seen that. Was basing it on the comment in this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=463111
>
Yeah, the wireless drivers are "special" since the vendor drivers, as
stated elsewhere, usually supply their own entire 802.11 stack and other
ugliness. I don't want to speak for John, but I suspect if someone
stepped up to maintain a staging wireless driver in the interim, he
wouldn't object.
I'm pretty much going to WONTFIX any bugs that show up for
wpa_supplicant and NetworkManager that have anything to do with staging
drivers. If the drivers were actually in the kernel (and no, staging
isn't really "in the kernel" because they are TAINT_CRAP) then yes, I'd
care, because the driver has passed a quality bar. None of the staging
drivers have done that, and most staging wireless drivers are likey
*never* to.
Part of that quality bar includes (a) using cfg80211, and (b) using
mac80211. If they do that, they get all the nice bug fixes and
attention that upstream kernel provides. If a staging driver with a
future (ie, ar9170/otus, at76_usb) shows up, then yeah, I'll care.
But if you're only doing "maintenance" on a staging driver, you're
almost certainly not porting it mac80211 and cfg80211 (otherwise you'd
actually be "developing" it, not just doing maintenance). Thus your
effort is mostly pointless.
Dan
2:40 a.m.
On 08/07/2009 12:31 AM, Kyle McMartin wrote:
>
No we haven't, we've stated that they'll be enabled if someone steps up
to the plate to make an active contribution to maintenance and
improvements.
https://fedoraproject.org/wiki/KernelStagingPolicy
Much appreciated. Insight into why things are the way there are is
always very useful. Thanks for documenting these sort of things.
Rahul
9:52 a.m.
On Thu, Aug 06, 2009 at 05:14:01AM -0400, Orcan Ogetbil wrote:
On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote:
> On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote:
>>
>> I maintain those drivers at RPMFusion. I will be happy beyond
>> imagination when the staging drivers are marked stable.
>
> They won't ever (the rtxxxx Vendor drivers)
>
>From my understanding, the staging tree of the kernel contains drivers
that are being prepared to be included in the main kernel tree[1].
Correct me if I'm wrong.
You are essentially wrong.
The drivers in the staging tree may or may not make their way to the
main kernel. I'm sure Greg and others hope that they will, and at
least some of them probably will. Unfortunately, none of the wireless
drivers there appear likely to do that.
Beyond the normal atrociousness of the code common to nearly all
of the vendor-supplied staging drivers, the wireless drivers also
tend to ignore the wireless infrastructure supplied upstream.
This includes both the mac80211 component of "soft MAC" devices
and the cfg80211 configuration component for all wireless devices.
As a community, we are refusing to accept drivers that duplicate
the mac80211 functionality and now we are requiring the use of
cfg80211 for new drivers as well. We simply can't afford to support
multiple implementations of the "soft MAC" functionality and the older
'wireless extensions' API is too broken and bug-ridden for continued
promulgation.
The drivers in staging are best used as a guide to the workings of
the hardware. I understand your desire for rt2860 and other devices
to be supported, but the staging drivers just aren't acceptable.
I would encourage you to put your efforts towards improving the rt2x00
driver family instead of propping-up the drivers in staging.
Hth!
John
--
John W. Linville Linux should be at the core
linville(a)redhat.com of your literate lifestyle.
4:03 a.m.
> Good luck with that! This driver has been in the process of
being
> re-written for well over a year, I've long given up hope. Its
> unfortunate as its in alot of netbooks including all the atom based
> eeePCs. Fortunately rpmfusion has one that works reasonably well (it
> even suspends and resumes!) appart from spewing massive amount of
> debug into /var/log/messages (if left on about half a gig a day).
>
> Peter
>
I maintain those drivers at RPMFusion. I will be happy beyond
imagination when the staging drivers are marked stable. It would save
me a lot of work, for it's not just rt2860, but also rt2870 and
rt3070. I keep writing patches and hacks to them for almost every
kernel update since Ralink is a bit slow with kernel updates. I'm glad
they are working though :)
I'm very glad of your efforts..... a massive THANK YOU!
Now I just wish the rewrites of the driver would speed up somewhat :)
Peter
5412
days inactive
5413
days old
24 comments
11 participants
participants (11)
-
Adam Williamson -
Conrad Meyer -
Dan Williams -
drago01 -
John W. Linville -
Kyle McMartin -
Markus Kesaromous -
Orcan Ogetbil -
Peter Robinson -
Rahul Sundaram -
Thorsten Leemhuis