On Thu, 13 Nov 2008, Pavel Roskin wrote:
On Thu, 2008-11-13 at 12:54 -0800, Luis R. Rodriguez wrote:
On Thu, Nov 13, 2008 at 12:48 PM, Pavel Roskin <proski@xxxxxxx> wrote:
Just my advice: let MadWifi die already, stop wasting your time.
Good advise.
Specifically for me - just three letters. DFS.
Why are you worried about DFS?
There is only one feature that is important:
Reliability. It has to work for months, without rebooting.
Consider a very reasonable use of madwifi - in a linux router. It has to
work reliably - without being rebooted by the user.
Consider an AP box that had madwifi in it. Every couple of days, the user
has to reboot it to get the box to work again. The user gets upset and
returns the box. This is not a commercial product. Yes, the box did DFS,
but it had to be rebooted regularly.
While the DFS is nice - it is not reliable.
Now - you have noticed the comments about SMP issues in this thread.
Do you know what that implies? There are races races races in the code.
There are contention issues. What is the only reliable fix for SMP?
complete redesign. Pull the code apart - and work out what each tasklet
and interrupt does. Ensure there is no contention.
Have you noticed the long standing bugs in the bug tracker? Stuck beacon,
ping ramping in adhoc. Do you know why these bugs are long standing?
Cause noone has the skill/ability/knowledge to fix them. ((Sure, there is
a purported fix for ping ramping - but this fixes the symptom, not
cause)). I have a fix for ping ramping - it required a complete redesign
of the codebase. I can report it, and give you the code, but you cannot
use it in madwifi cause it breaks wds, scanning, dfs, ap, sta modes.
The options are clear::
a)Fix stabilise madwifi
or
b)add features to mac80211
a is a lot of work in a short lived project
b is a lot of work in a project that is going to be around for years.
===================================
Sure, if we abandon development on madwifi - we are breaking our promise.
Given the current rate of development, we will not be able to provide a
stable reliable code base with DFS etc in the promised timescale. thus, if
we continue developing madwifi, we will fail to meet objective, and end up
breaking our promise in the future.
Conclusion:: break the promise now, or later.
As an end user of madwifi, it is more reasonable to break the promise now.
I end up being forced to agree with Luis:
Just my advice: let MadWifi die already, stop wasting your time.
Derek.
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek@xxxxxxxxxxxxxx
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
