Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Michael Renzmann <mrenzmann <at> madwifi.org>
Subject: Future of the MadWifi driver
Newsgroups: gmane.linux.drivers.madwifi.devel
Date: Tuesday 16th September 2008 06:23:41 UTC (over 8 years ago)
Hi all.

It seems necessary to start a discussion about the future of the MadWifi
driver. The following post will be a bit lengthy, but I think an
introduction is required.

Back in September 2007, when we announced [1] to move away from the binary
HAL in favour of ath5k, we declared MadWifi legacy. At the same time we
promised:

"In the long run ath5k will replace the MadWifi driver. For the time being
MadWifi will still be supported, bugs will get fixed and HAL updates will
be applied where possible. But it becomes unlikely that we'll see new
features or go through major changes on that codebase. The only exception
to this is the work spent on improved support for [DFS]."

We had lengthy discussions before we published our decision. In the end
there was a consent that ath5k will need a fair amount of time before it
is more or less up to par and able to replace MadWifi for most users. For
this we decided it's necessary to continue working on MadWifi, to make
sure that people have a stable driver they can use until ath5k is mature.


The status quo, however, looks totally different:

The last stable release, v0.9.4, happened more than seven months ago. In
the meantime two new major kernels have been released which are not
supported by 0.9.4. The release also lacks support for current and
wide-spread hardware (AR5007 and AR5008).

trunk has diverted *a lot* from what v0.9.4 is based on. Actually, v0.9.4
is v0.9.3 (r2200) plus some security fixes plus a number changes
backported from trunk. trunk, on the other hand, is now at r3866 - that's
more than 1600 changes. Plus, trunk is known to have a good number of
stability issues and thus can not easily be used to make a new release.

To address at least some of these issues, Pavel has started working
towards release 0.9.4.1. Where possible he has backported changes from
trunk. A major issue has been identified as blocker for the new release
[2], but nobody is either able or willing to help resolving this issue.
Until this changes, 0.9.4.1 is a dead end.

Active work on the driver takes place in separate branches (madwifi-dfs)
or even separate repositories (openwrt.org, where nbd works on stabilizing
the driver and fixing bugs). It turned out that merging the results of
these efforts back to trunk ranges from "damn hard" to "virtually
impossible" for various reasons which makes much of the work spent there
unreachable for trunk.

The HAL is another major pain. trunk still uses HAL 0.9.30.13, which has
known bugs. Atheros provided us with HAL 0.10.2.2 [3] to allow for AR5007
support, but it was incomplete in terms of supported architectures (32bit
x86 only) and thus was no option for trunk.
After more than a year without any release, Sam not too long ago published
HAL 0.10.5.6; while it comes with AR5007 support and fixes some of the
bugs that are in 0.9.30.13 it also introduces new issues, and again is no
option for trunk. Which pretty much left trunk in a dead end for a while.

Some weeks ago nbd told us that soon a new HAL will be made available. It
should fix known issues, introduce support for new architectures and, most
important, is planned to be actively developed and supported. In other
words, this new HAL seems to be a sword that's capable of finally cutting
the Gordic knot.
The HAL has been released two weeks ago, but we still didn't manage to
post a note about it to this list to tell people about it and ask them for
help with testing it.


Bottom line (from my point of view): MadWifi currently is caught in a dead
end. And although there is a road available which promises to lead us out
of the misery, it seems most team members are either not willing or don't
have enough energy/motivation left to take this road.

Hence I'd like to pose some questions:

Am I wrong about my conclusion? Did we silently say good-bye to MadWifi
without noting it? If so, why is that? And how should we go on from here?

Input from the community is of course also appreciated.

Bye, Mike

[1]
http://madwifi.org/wiki/news/20070920/madwifi-moves-away-from-binary-only-hal
[2] http://madwifi.org/ticket/1903
[3] http://madwifi.org/ticket/1679


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
 
CD: 2ms