Hi Derek, list,
On 29/09/2008, at 2:03 PM, Derek Smithies wrote:
> I am writing this letter to try to work out if there is a point in
> putting more work into the madwifi project. Apologies for the length.
> My colleague (less informed about the madwifi project than myself)
> had a
> long discussion on this topic. From this discussion, several points
> 1)The madwifi project is a duplication of the athk project.
> athk has fewer features than madwifi.
> This is "true", but then we asked, "so what"? Which is more
> There is no point in having "features", if the core functionality
> is not
> reliable. The current trunk is so unreliable that there is serious
> discussion about moving to OpenWRT's code base (based off r3314).
> In a mature code base, one expects the core functionality to work
> reliably - the new features don't break things. It is in the junior
> startup projects that operation is "hit and miss".
And of course, that's the problem with madwifi. It has never been
treated as a mature code base, and hence no quality controls were put
in place to stop the code from deteriorating. I think the only time
there was any sort of quality control was for the 0.9.4 release.
> 2)The brandname of "madwifi" is associated with (in the open source
> community) the words,
> "non free", "non GPL", "proprietary blob".
> Even with a massive reeducation program, it is going to take some
> to convince people it is now OK.
> -Simpler to select a new brandname and release that. Either approach
> takes time and effort.
I think we all know this, and to be honest its not an issue. I don't
think anybody ever expects madwifi to ever be seen as a completely
> 3)The code will (even with a GPL license on everything) never make
> it into
> the kernel.
> The kernel people will say
> a)duplication of the mac80211 network stack
> b)non standard config tools
> c)duplication of the ath5k project
> d)yucky code base. - code is not to kernel standard.
We all know this too and I don't think that anybody expects (or cares)
if madwifi gets into the kernel proper or not.
> 4)But what of existing users?
> Exactly. Exisiting users have madwifi code that sort of works. At
> current levels of functionality, madwifi is better than ath5k.
> But for how long? Given the new level of knowledge on the atheros
> hardware, we will (hopefully) see rapid advancements in the ath5k
> project. This is happening with the latest round of patches.
> This is the hardest question in software engineering. When do you
> work on one approach to solve a problem, and start work on another
> approach to solve the problem.
> Alternatively, which will take less effort:
> Fix/improve ath5k to work for all users in all the modes (ap,
> sta, etc)
> Fix/improve madwifi to meet this goal.
> Well, the arguement that ath5k did not support all hardware
> supported by
> madwifi has (effectively) gone. Now, the information to make ath5k
> support the hardware currently supported by madwifi is available.
Given the nature of kernel development I honestly think this
transition will happen organically. I don't think anybody expects
madwifi to be seriously developed any further (new features, etc).
However, there is a significant user base who use madwifi and should
be remembered. There are still bugs that will need fixing, security
issues that need addressing, new kernels to stay compatible with.
Madwifi still needs to be maintained at least for a while. That
doesn't mean that we need to put significant effort into improving
madwifi though, it just means that it still needs to be maintained.
I imagine that the easiest way forward for madwifi is simply to take
OpenWRT's tree, use it for a bit, release it as 0.9.5 and then go into
Even though the majority of users are laptop users who simply need a
single, encrypted station VAP, there are still plenty of people
creating AP devices who need AP mode (working today, not in 6 months
time), encrypted AP, multiple VAPs, SoC support, etc. Madwifi does all
this and it seems that it would be a waste to simply drop it. That's
not to say that development on these features should not be done on
ath5k, but that there _is_ a case for keeping Madwifi around for a bit
longer. OpenWRT's tree is nice given that it is targeted at the kind
of users that ath5k doesn't support yet.
> 5)What is the current level of interest in the madwifi project?
> I pulled the whole svn repositary, and did a
> svn log | cut pipe whatever,
> and found 840 lines of the format:
> r2723 | mrenzmann | 2007-10-05 03:07:39 +1300 (Fri, 05 Oct 2007) |
> 16 lines
> and then counted the number of commits in each month
> Now, October refers to the number of commits in october of last year.
> September refers to the number of commits in Sep of this year
> Oct 65
> Nov 105
> Dec 109
> Jan 108
> Feb 39
> Mar 48
> Apr 108
> May 98
> Jun 54
> Jul 75
> Aug 17
> Sep 14
> Now, admittedly project activity varies as peoples interest/time
> The drop in the last two months is quite steep.
Interesting, but ultimately, meh. Of course with athk interest
will drop in madwifi, people come and go, etc.
> 6)Code quality.
> Structuraly, the code is a mess. Consequently, it is very hard for
> to edit with a high degree of confidence in not breaking things.
> The documentation, such as the page on locking
> is lacking depth, insufficient, and is it still correct?
> Where is the description of each lock???
> Ideally, code documents its intent by the choice of names, layout and
> partitioning. Many places in the kernel are an example of this.
> Madwifi fails this test. The intent is obscure.
Again, we know there are glaring problems with the code and the
documentation. Madwifi has never had any sort of quality control on
either. This is probably because everyone knew it would never make it
into the kernel anyway so "why bother?".
> I see no point in continuing madwifi development.
> here is the challenge.
> I am not the first to say on this list "no more development".
> Can those who think there is a need for development, please speak up.
To be completely honest, I'm not sure why there has to be so much talk
about all this. athk exists and are clearly the way to go for new
development. Madwifi doesn't need new development, but it does need
one final round of tidying up as well as ongoing maintenance. If
people don't want to touch madwifi again, fine. It's their choice.
That doesn't mean that madwifi should simply be dropped though. A
shift of developer resources will happen organically as people become
comfortable with the new way of doing things. I don't think there's
really much need for the "project" to stand up and say, "no more
development on madwifi!" Just let it happen naturally - it will.
The real pressing issue is what to do with trunk? The options, as I
see them, are
1) Give up on trunk, give up on madwifi, let people continue to hack
on it if they want.
2) Switch to OpenWRT's tree, make a release, enter permanent
3) Try to salvage something out of our own tree.
Option 3 requires the most work, and to be honest, doesn't seem worth
it. Option 1 seems like a huge waste. Option 2 seems the most
realistic and most likely to be useful and is the one I'd like to see
Those are my thoughts anyway.
WAND Network Research Group
Department of Computer Science
University of Waikato