Bug 202528

Have you read http://fedoraproject.org/wiki/Packaging/KernelModules?  Can you
provide the requested information, in particular:

 * A publishable explanation from the author(s) why the module is not merged
with the mainline kernel yet and when it's planed to get merged. You of course
can ask the author to explain it directly in the bug report.

rt2x00 is in development and will be merged with the mainline kernel as soon as
it will be ready, this is planned! (and then provide kernel module for all
ralink wifi chipset)

But there is a bug and rt2x00 cannot be built on fedora
( i'm searching for already submitted bug... )

asking publishable information from the author...

quote of IvD:
*  Ivo van Doorn (aka IvD)
   o Source-rebuild rt2x00 main developer
   o rt2400/rt2500 Source Code fixes and enhancements 

"The legacy drivers: rt2400, rt2500, rt2570, rt61 and rt73 will _never_ be
merged with the kernel tree since they do not comply with any of the kernel
coding rules.
The design is ugly, it is not portable and is buggy on SMP and PREEMPT enabled
machines, and is even more buggy on big endian machines.

rt2x00 already is in the wireless-dev tree and will be merged upstream when
rt2x00 and the dscape stack are stable. When they are it would also finally
resolve the solution that rt2x00 is not working with Fedora Core kernels because
he Fedora Core kernels are so heavily patched that the API of certain structures
have changed and external module compilation will always fail. "

Answear about how much time it will take will follow...

Question about how much time...

quote of IvD:
"Well it all depends on when rt2x00 is considered stable, dscape might make it
to the main kernel tree within a few months.
How soon rt2x00 follows afterwards really depends on how fast successes are
being achieved with the last few issues regarding association time and the
remaining RX issues.
So no schedule can be given for neither the next rt2x00 beta, the final rt2x00
or rt2x00 moving to main kernel tree.
rt2x00 will be considered stable when it is stable. "

I see a lot of theses Ralink wifi chipset in computers around me, but not so
much drivers for Fedora or other distributions... That 's why i've made a
pre-compiled module for FC5 (may work with FC4 and legacy!)
Obviously it may be better than using Ndiswarper...
The driver will be osolete as soon as the rt2x00 can build on a Fedora kernel...
( compilation fails for rt2x00- here is somme info :
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=12631#12631)

I don't know if a bug is already submitted for this issue...

Spec URL: http://kwizart.free.fr/fedora/SPECS/rt2500-kmod.spec
SRPMS URL:
http://kwizart.free.fr/fedora/5/SRPMS/rt2500-kmod-1.1.0.cvs2006081716-4.2.6.17_1.2174_FC5.src.rpm
Description: Kernel module for RT2500 wireless devices 

Ok i've made a new update conforming to naming rules...

rpmlint -i kmod-rt2500-* (only one kind of warning)
W: kmod-rt2500 summary-not-capitalized rt2500 kernel module(s)
Summary doesn't begin with a capital letter.
kmodtool reason %{name} kernel module(s)

W: kmod-rt2500 unstripped-binary-or-object
/lib/modules/2.6.17-1.2174_FC5/extra/rt2500/rt2500.ko
What does it mean?

W: kmod-rt2500 no-documentation
rt2500-kmod-common provides documentation...

W: kmod-rt2500-kdump filename-too-long-for-joliet
kmod-rt2500-kdump-1.1.0.cvs2006081716-4.2.6.17_1.2174_FC5.i686.rpm
This filename is too long to fit on a joliet filesystem (limit is 64 unicode chars).
Can i solve it?

src.rpm
W: rt2500-kmod mixed-use-of-spaces-and-tabs
The specfile mixes use of spaces and tabs for indentation, which is a
cosmetic annoyance.  Use either spaces or tabs for indentation, not both.
May i fix? tool for this?

Depends on RutilT

I don't think it should Require RutilT, since the wifi card can be configured
using command-line tools.
RutilT would bring way too much dependencies (like Xorg...) for a simple wifi
card driver.
This would be a good use case for the Suggests tag that rpm CVS has. But not yet.

This is true. RuiltT is not necessary to setup the card. I will drop the
requires tag next time... In fact , it is easier NOT to use this tools but
system-config-network (that have been reported by some users!)

About the release in extras repository, i think i will close this bug because
rt2x00 version can now be built on fc5 with a quick patch. I still trying to
have working impressions from users then i will open a new review request titled
rt2x00-kmod...

(I don't expect i will be necessary to have both version!)

> About the release in extras repository, i think i will close this bug because
> rt2x00 version can now be built on fc5 with a quick patch. I still trying to
> have working impressions from users then i will open a new review request titled
> rt2x00-kmod...

Great, I have an USB dongle with a ralink chipset so I can test this. Please
post the bug number here when you've submitted it.

Spec URL: http://kwizart.free.fr/fedora/testing/rt2x00-kmod.spec
SRPMS URL:
http://kwizart.free.fr/fedora/testing/rt2x00-kmod-0.0.0cvs20061002-1.2.6.17_1.2187_FC5.src.rpm
Description: Kernel module for Ralink wireless devices.

Spec URL: http://kwizart.free.fr/fedora/testing/rt2x00.spec
SRPMS URL:
http://kwizart.free.fr/fedora/testing/rt2x00-0.0.0cvs20061002-1_FC5.src.rpm
Description: Kernel module for Ralink wireless devices (common part).

Don't know how to use make install script...

rpmlint -i (partial) :
W: kmod-rt2x00 unstripped-binary-or-object 
Don't know how to fix this...

I've decided to follow with this review request because some info about the
module and when it is planned to be merged is already there. rt2x00-kmod-common
is on the same review (so i will close the old rt2500-(kmod-common) ). I expect
it will be fine...

Please note that some rt61 and rt71 chipset will need to download a firmware
from Ralink: (to /lib/firmware !)
http://www.ralinktech.com/drivers/Linux/RT61_Firmware_V1.2.zip
http://www.ralinktech.com/drivers/Linux/RT71W_Firmware_V1.8.zip

Updated rt2x00-kmod from Ville Skyttä example (madwifi).
It seems to be a quite clean compilation! 

%prep
Setup ...
grep -rlF '<linux/config.h>' acerhk-%{version} \
| xargs sed -i -e 's|<linux/config.h>|<linux/autoconf.h>|' 

Any idea when this kmod package will be accepted on extras?

rt2x00-kmod
SRPMS URL:
http://kwizart.free.fr/fedora/5/SRPMS/rt2x00-kmod-0.0.0cvs20061017-1.2.6.18_1.2200.fc5.src.rpm
SPEC URL: http://kwizart.free.fr/fedora/SPECS/rt2x00-kmod.spec

rt2x00
SRPMS URL:
http://kwizart.free.fr/fedora/5/SRPMS/rt2x00-0.0.0cvs20061017-1_FC5.src.rpm
SPEC URL: http://kwizart.free.fr/fedora/SPECS/rt2x00.spec

rt61-firmware
SRPMS URL: http://kwizart.free.fr/fedora/5/SRPMS/rt61-firmware-1.2-1_FC5.src.rpm
SPEC URL: http://kwizart.free.fr/fedora/SPECS/rt61-firmware.spec

rt73w-firmware
SRPMS URL: http://kwizart.free.fr/fedora/5/SRPMS/rt71w-firmware-1.8-1_FC5.src.rpm
SPEC URL: http://kwizart.free.fr/fedora/SPECS/rt73w-firmware.spec

(In reply to comment #12)
> Updated rt2x00-kmod from Ville Skyttä example (madwifi).
> It seems to be a quite clean compilation! 
> 
> %prep
> Setup ...
> grep -rlF '<linux/config.h>' acerhk-%{version} \
> | xargs sed -i -e 's|<linux/config.h>|<linux/autoconf.h>|' 
> 
> Any idea when this kmod package will be accepted on extras?

A few things bother me about this package.  It's not just shipping a driver for
rt2x00 hardware.  It's shipping a whole new 802.11 network stack that isn't
included upstream yet.  I would really like to see the dscape stack broken out
into a separate kmod package at the very least.

Also, the README file explicitly states that compiling against Fedora kernels is
problematic.  Fixing the problems requires a non-trivial understanding of both
the device driver, and the generic kernel code it's calling.  The upstream
developers will not even provide compilation steps for this.  Do you, ask the
packager, have the knowledge to either fix these issues as they arise, or work
with upstream to get the resolved quickly?  Because if not, this package is
doomed to lag behind and users will not be able to update their kernels, etc.  

The README also goes as far as to suggest complaining to the Fedora developers.
 That is most certainly not the right thing to do.

First I would like to thank you to answear this review. I'm not a packager
throught i need to be sponsored for packages in FE extras...

But... please notice that making a kmod on FE (in general) in the state of the
policy is a "perfect double bind" which leads to make schizophrenic packagers.
On one hand, kernel modules have to be inside the kernel tree, on the other
hand, when they are in development, why integrate them inside a kmod if they are
not as good as for the kernel. The kmod aims isn't to make easy updatable kernel
module out of the kernel tree because they require this in fact (for their
development!?!

The choice a user of a ralink wifi chipset has in fact is to use the Ndis scheme
based "module" - so why can we ask the vendor of such scheme to develop wifi
module for linux ? Wifi users have the choice actually - But they sould have the
choice to use linux module too... (when they are avaible - and it is the case
for now!)

I agree with you the situation isn't satisfaying with the d80211 stack. But make
a different kmod for this seems to be more problematic because it deals with
versions that different wifi module will use! There is the netdev kernel issue
for this specific problem (d80211 stack is in netdev in think?)

The compilation problem is more difficult to me. Now it works fine! I expected
it was since kernel 2.6.18-1.2200.fc5 was released but it seems to be more
difficult: So that's the point! Here is the discution with the developper (IvD):
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=15075#15075

People will not be able to update their kernel with the kmod-rt2x00 package nor
to compile themselves the rt2x00 package for most of them nor to use an old
rt2500 rt2400 rt2570 etc version because they are so buggy on smp and
unstable... So the last chance for them is to dual-boot a kernel until it
works... (thought this is not satisfaying for me too!)

That's all for now - I will try to fix this but i'm not a programmer - i'm just
a student in architecture...  So your help is welcome! Thx one second time to
answear this post!
Nicolas

I have to correct something : there is no d80211 stack with the netdev kernel...
(2.6.18-1.2200.2.9.fc5.netdev.13 (or i did not find it...)

So i've done a d80211 only package... This is for testing only! Maybe usefull
for bcm43xx with DeviceScape 802.11 stack or other if not, i cannot see any
interested! But for now, there is no devel package. I need to figure which files
are needed...

d80211(-kmod-common)
SRPMS URL:
http://kwizart.free.fr/fedora/SOURCES/d80211-0.0.0cvs20061022-1_FC5.src.rpm
SPEC URL
http://kwizart.free.fr/fedora/SOURCES/d80211.spec

d80211-kmod
SRPMS URL:
http://kwizart.free.fr/fedora/SOURCES/d80211-kmod-0.0.0cvs20061022-1.2.6.18_1.2200.fc5.src.rpm
SPEC URL:
http://kwizart.free.fr/fedora/SOURCES/d80211-kmod.spec

I've done a little error with the name of the spec:
rt71w-firmware
SRPMS URL: http://kwizart.free.fr/fedora/5/SRPMS/rt71w-firmware-1.8-1_FC5.src.rpm
SPEC URL: http://kwizart.free.fr/fedora/SPECS/rt71w-firmware.spec

Where are you pulling the stack from?  Is it straight from wireless-dev?

You d80211 packages seem to come straight from the rt2x00 project.  I think 
you should have a clean extract of the code from wireless-dev if you are doing 
to create a d80211 package.

A d80211 package ought to be driver-agnostic, not tied to the rt2x00 driver.

kmod was approved by FESCO as long as the issues Linville (and the review
itself) brought/brings up get solved.

I just received my rt2x00 based wireless card and wanted to give a try to your
packages. Unfortunately all the kmod rpms are missing from
http://kwizart.free.fr/fedora/6/x86_64 
What's up? Just a temporary problem?

Please let me know if you want me to continue this discussion off-line. I tried
to  compile the sources in http://kwizart.free.fr/fedora/6/SRPMS 

rpmbuild --rebuild rt2x00-kmod-0.0.0cvs20061017-1.2.6.18_1.2798.fc6.src.rpm

it compiles but

 rpm -Uvh kmod-rt2x00-0.0.0cvs20061017-1.2.6.18_1.2798.fc6.x86_64.rpm error:
Failed dependencies:
        rt2x00-kmod-common >= 0.0.0cvs20061017 is needed by
kmod-rt2x00-0.0.0cvs20061017-1.2.6.18_1.2798.fc6.x86_64


Uh? Where is the rt2x00-kmod-common package? I had an intuition so I did

 rpmbuild --rebuild rt2x00-0.0.0cvs20061017-1_FC5.src.rpm 

Note the FC5. ... it compiles but still no "common", ok so it was a wrong intuition

but then I tried

 rpm -Uvf rt2x00-0.0.0cvs20061017-1.kwizart.fc6.noarch.rpm
kmod-rt2x00-0.0.0cvs20061017-1.2.6.18_1.2798.fc6.x86_64.rpm

And it installs .... I guess you have serious problems in naing your packages
and mantaining your dependencies. Let me know if I can be of any help

Beppe

FC6 are only build on i386 because i'm making a transition between FC5-FC6. I
wish  it exist an "external built from extras" that would be possible. But i
will drop "testing" support on wy website for FC5(and gain support for fc6 in
few days i hope...).

I also cannot use my signing key for rpmsign. It works for gpg but not for
rpmsign, i don't know why! Feel free to mail me for this issues,...

You can have more informations about my test repository here: (in french!)
http://kwizart.free.fr/blog
-----

Thank you John W. Linville to answear this review! I plan to try this tommorrow!
The first thought is : if the d80211 code is modified then it may has a good
reason. And that's why it cannot be inside the vanilla kernel! 
Another thought is if a person needs the rt2x00-kmod he probably do not needs
another based d80211 wifi chipset module (like bcm43xx, but there is certainly
others planned!).So i wonder if it is a good choice to make two differents
packages before d80211 will be inside the kernel tree?
I will try to investigate with some example...

I also tried to make a kmod with the netdev kernel but i didn't riched! any
tips? the netdev suffix do not seem to be "in a name"...


I also thanks Thorsten Leemhuis for his well-documented kmod scheme! I've read
the FESCo meeting about rt2x00 but I have 6days of decay...
I expect the approval is for rt2x00-kmod! It is a good news, but the less better
one is that users seems to report difficulties to the setup step. There is a
manual setup protocol witch gives better results (iwconfig - See the readme)
whereas the automatic scripts setup (system-network-config) send the command too
fast for the device...I thought it was about miss-versionning between
wireless-extension V20 and wireless-tools V19 on FC5. I will see what's happen
on fc6 next days...
So i hope it can be at least on testing for fc6!

I'm also still considering the comment #13 by Josh Boyer. 
Maybe more info about this when a future testing kernel will avaible. 
I will then reference a bug about this issues and a kernel-testing!




I will try to investigate this with

Compilation works with the testing kernel-2.6.18-1.2835.fc6 (same url)

d80211(-kmod-common)
SRPMS URL:
http://kwizart.free.fr/fedora/SOURCES/d80211-0.0.0cvs20061110-1.kwizart.fc6.src.rpm
SPEC URL
http://kwizart.free.fr/fedora/SOURCES/d80211.spec

d80211-kmod
SRPMS URL:
http://kwizart.free.fr/fedora/SOURCES/d80211-kmod-0.0.0cvs20061110-1.2.6.18_1.2835.kwizart.fc6.src.rpm
SPEC URL:
http://kwizart.free.fr/fedora/SOURCES/d80211-kmod.spec

I will work on the linville issue, when i will have more time... 
Any answears, felling or thoughts to the question i ask?

Thx
Nicolas

FWIW, I have included a d80211 patch in my FC6 test kernels:

   http://people.redhat.com/linville/kernels/fc6/

This is not directly related to packaging, but it might be interesting to 
anyone stumbling upon this bug.

Which command sould I use to grab the same version of the d80211 than the one
you used in the "jwl" testing kernel? i grab the whole wireless-dev tree when
trying to made a snapshot with a script...

The main command was:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
wireless-dev-$git

Can i grab only d80211, bcm43xx(if your version is d80211 based not soft_mac!)
and then rt2x00 witch is currently not in the wireless-dev tree for now! Maybe
others ones are fine to be built with the d80211 stack (hostap, atmel or others?)

I will try to take the tree last d80211 patches; and then see if i can replace
the d80211 stack version included from rt2x00 with this one... does it sounds good?

The last commit before generating that patch:

   39d58f9228dee66c22ce1b1d314c8012b892ea4d

FWIW, the raw patch needed a little massaging before it would build on FC6.  
You may want to look at the patches from the fc6.jwltest kernels for 
inspiration.

The d80211 tree has a number of drivers available, including bcm43xx, rt2x00 
(look closer!), adm8211, and p54.  Intel is supposed to make an ipw3945 driver 
available for d80211 "soon" as well.

I would be happy to discuss a tagging regime for wireless-dev if that would 
facilitate packaging.

I would love to have a solid rt2x00 package for Fedora Core 6.  I'm currently
running FC 6 with an FC 5 kernel, because I haven't been able to get a stable
system using either the older rt61 driver (which is what I use under FC5) or the
rt2x00 driver.

@Danny Yee
rt2x00 is in development and sould be considered stable when d80211 stack will
be in the kernel tree.. (not until 2.6.21 kernel and rt2x00 should certainly be
integrated with it).
You can try my testing repository here : 
http://kwizart.free.fr/blog/index.php?17
http://kwizart.free.fr/blog/index.php?10
You can try both rt61 and rt2x00 kmod for fc6, try the rt2x00 first and then
rt61.Don't forget the rt61-firmware for it (rt2x00 only!)
(it 's in french but i can provide you support in english!)

In fine it will help the review...

@John W. Linville
I've took theses files to build the d80211 kmod:
http://people.redhat.com/linville/kernels/fc6/patches/jwltest-d80211-backport.patch
http://people.redhat.com/linville/kernels/fc6/patches/jwltest-d80211-backport-fixup.patch
http://people.redhat.com/linville/kernels/fc6/patches/jwltest-cfg80211-fixup.patch

I spent few time upon this question but last time i've found that rt2x00 from
serial monkey do not works with the patches you provides or needs some tweaks.
So the direction i'm involved is to take rt2x00 version from the patches you
provides which is not the same package thought... (but certainly a better
stable... less support?)

wip...

Since users still report failing (most of the time with association with ap) I
think this is too much early to split the package...
Recent involvement of the module can enable the debugfs inside a recent kernel
(2.6.18 but only work with fedora and this module since 2.6.19-1.2895.fc6)

So it would be interesting in trying to help and report feedback, See:
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2695

A more recent version:
SRPMS
http://kwizart.free.fr/fedora/6/SRPMS/rt2x00-kmod-0.0.0cvs20070113-1.2.6.19_1.2895.fc6.src.rpm
http://kwizart.free.fr/fedora/6/SRPMS/rt2x00-0.0.0cvs20070113-1.kwizart.fc6.src.rpm

SPECS:
http://kwizart.free.fr/fedora/SPECS/rt2x00.spec
http://kwizart.free.fr/fedora/SPECS/rt2x00-kmod.spec

Also notes that hostapd and wpa-supplicant need to be patched in order to work
with rt2x00 version (d80211 from rt2x00 repository - i don't know yet about
wireless-dev version!)
See also on the :
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2434

The rawhide kernel as of 2/25/2007 currently has the d80211 stack and the rt2x00
drivers included in it.  Please test this kernel out and report any issues to
the kernel maintainers.

For the most part, the inclusion of these drivers in the rawhide kernel has
rendered this bug obsolete.  I'll leave it open for now, but it will likely get
closed in the future.

Nicolas: Can we go ahead and close this now since the d80211 versions are in F-7
and devel now? 

I will close this and if you disagree or have a reason to keep it open, you can
feel free to re-open it. Thanks. 

I agree! thx for closing this bug!

About Ralink's devices:
I will submit RutilT soon as this utility seems to help to configure some rt2x00
based devices.
There is also two firmwares that need to be reviewed (but missing license may be
a blocker for now...)