Thread: [Madwifi-devel] Future of the MadWifi driver
Status: Beta
Brought to you by:
otaku
From: Michael R. <mre...@ma...> - 2008-09-15 23:23:50
|
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 |
From: Scott R. <sco...@gm...> - 2008-09-16 00:03:08
|
Hi Michael, On 16/09/2008, at 6:23 PM, Michael Renzmann wrote: > 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. > ... > > Bye, Mike All valid points. Trunk is in a pretty sorry state - internally I use 0.9.4, and I simply have no time to start trying to figure out how to get trunk into a useable state. For one, I can't get it to operate in AP mode reliably, which is a major pain. However, there have been plenty of commits to trunk which would be great to have. Felix's new HAL really should be used ASAP. More hardware support, more architectures, and presumably fixes for ANI, etc. However, I haven't been able to reliably test it given that the HAL branches are based off trunk which is buggy already. I'd be willing to spend some time on the following: 1) Branch 0.9.4(.1) 2) Integrate Felix's new HAL, which requires changes around the "new" descriptor API. From there, as a community we could start going through trunk and picking out changes that look good, in a similar manner to how we managed the release of 0.9.4 (which I think went really well). This will probably require re-writing large portions of patches, but oh well. Essentially this means giving up on trunk. We might even want to copy trunk to its own branch and then make trunk start again from 0.9.4 with some peer-review as to what gets committed. I'd be quite happy to be involved in this process. I know there will be people who say, "why spend time on madwifi when ath[59]k are there?". Well, ath[59]k (and mac80211) simply aren't ready for users who need to use madwifi for anything other than simple STA mode. There's no way I could run my network with ath5k at the moment, which is not to say that I never could, but I simply don't have the time to get ath5k and mac80211 working. As for the recent lack of activity on madwifi, I think what has really happened is that people using madwifi have stopped following trunk and have instead just kept their own trees going, for example, OpenWRT. I'm just as guilty. However, with some co-ordinated and disciplined team-work I think we could get madwifi back on track. Also, let's delete some branches. SVN really isn't suited for lots of constant merging. Is there any use in having the hal-0.10.5.6 branch? Also, how are we going to get -dfs merged completely? I'd really like to see a plan for getting rid of -dfs ASAP. What about -tx-power? Would anybody miss it? Cheers, -- Scott Raynel WAND Network Research Group Department of Computer Science University of Waikato New Zealand |
From: Michael R. <mre...@ma...> - 2008-09-16 21:49:06
|
Hi Scott. Scott Raynel wrote: > I know there will be people who say, "why spend time on madwifi when > ath[59]k are there?". Well, ath[59]k (and mac80211) simply aren't > ready for users who need to use madwifi for anything other than simple > STA mode. >From what I know, active work is spent on adding AP mode to mac80211. Once that is done, it should not be too hard to add AP mode support to ath[59]k. What I wonder about is: how about the other functionality that MadWifi offers? Such as IBSS, monitor mode, multi-VAP support, all the Super A/G stuff, different rate control methods, ...? Which of those features are actually used by what share of the MadWifi users? It might be worth to start a survey for this. Is there any schedule yet for adding some of these features to ath[59]k, and what amount of work would be required to get them supported? Luis, any chance you can sched some light on (some of) these questions? > As for the recent lack of activity on madwifi, I think what has really > happened is that people using madwifi have stopped following trunk and > have instead just kept their own trees going, for example, OpenWRT. > I'm just as guilty. However, with some co-ordinated and disciplined > team-work I think we could get madwifi back on track. Personally, what I think the project currently lacks is one or more persons who is/are able and willing to coordinate things. In the past I've tried to fill this (and other) gap(s) as good as I could. But due to the growth of the project over the past months it'd now require a full-time employee to take care of all the different tasks I had in the project. At the same time the amount of available spare time decreased for me. That's why I began to step back from many of those tasks, to concentrate on administration of our servers and stuff. So far only a small number of the vacancies have been filled by other team members. It seems obvious to me that we have a motivation gap within the project - and there certainly are various reasons for this. I wonder if at this point we are able to motivate ourselves enough to get back to coordination and discipline... > Is there any use in having the hal-0.10.5.6 branch? Now that nbd's HAL is available, I think this branch is no longer needed. So far we pointed people looking for AR5007 support to this branch. We should now ask them to try madwifi-hal-testing instead. > Also, how are we going to get -dfs merged completely? That's a good question, but it probably requires a decision first about what happens to trunk. It would make no sense to finish merging -dfs to trunk if we decided to rewind trunk to an earlier revision, for example. > What about -tx-power? >From what I can tell, this branch has been started by mentor. However, he currently has no permission to directly commit to the repository, and from what I can tell he seems unwilling to take the steps that would be required to regain those permissions. But I might be wrong. Matthew? Bye, Mike |
From: Kel M. <ke...@ot...> - 2008-09-16 00:10:31
|
On Tuesday 16 September 2008 16:23:41 Michael Renzmann wrote: <snip> > 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. <snip> > 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? Haven't been silent about it really, I think Madwifi currently is dead without a doubt, at least those versions existing on madwifi.org. The development group also seem to function like a dysfunctional family recently too. The best path forward is to stabilise on the codebase nbd has been working on, which means a bunch of new work, and discarding a bunch of work that has already been done in trunk and other branches. No idea if nbd or others want to do this though. I certainly am unable to do it, or help in any meaningful capacity, therefore my opinion might count for nothing. Kel. |
From: Nick K. <mic...@gm...> - 2008-09-16 04:04:44
|
2008/9/16 Michael Renzmann <mre...@ma...>: > > 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? I also believe MadWiFi is dead and it's codebase is too messy for me to work on. Cleaning up the code would help a lot but it takes time and i don't think anyone is up to it, it also doesn't make sense to try to fix such a messy code when there is an open-source (and much cleaner) alternative out there. Some time ago i posted a to-do list on ath5k-devel... https://lists.ath5k.org/pipermail/ath5k-devel/2008-June/000964.html Most of this stuff (at least for the driver-part) are complete... * Bruno cleaned up rates and provided a function to match rate code from descriptors with it's rate * Jiri provided a testing patch for AP support (which seems to be working fine, i just have to do some more tests on my hw) * Bob cleaned up Led stuff and we now use mac80211 leds We need some work on multiqueue support. BMISS handling (and the whole stuck beacon issue) and RFKill integration (using GPIO interrupts etc). I believe that ath5k will be much better and that by Christmas with help from Atheros (we are looking fw for that) it 'll be much better than current MadWiFi (without support for special stuff like turbo/dturbo/fastframes/compression for now). I also believe that more people should start working on ath5k instead of trying to keep MadWiFi alive, i know it still misses features but we are just 4 people working on it and not with frequent patches etc, so you can't expect ath5k to have the features you want so badly if you don't do something. Don't just wait for ath5k to get the feature you want so you can start working on/with it. Right now ath5k supports all "legacy" (non-n) Atheros chips out there that HAL supports, with only RF problems (that means you can work on implementing MAC-related features like multiqueue -hw code is there btw- etc) so i don't think there is a reason for sticking with MadWiFi anymore. You can't make MadWiFi better but you CAN make ath5k better... -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick |
From: Michael R. <mre...@ma...> - 2008-09-16 22:11:38
|
Hi. Nick Kossifidis wrote: > I also believe MadWiFi is dead This is no real news, is it? It's the reason why we declared MadWifi legacy. > and it's codebase is too messy for me to work on. I think that's the main problem. Back then we decided to try stabilizing MadWifi such that it can bridge the time until ath5k (and now also ath9k) become mature enough to replace MadWifi for most users. >From what I remember, we originally assumed a rough time frame of 1 to 2 years for this to happen - is this still valid, or have things changed notably? Could it be that we were wrong about the time frame, basically because we have a wrong idea about which features of MadWifi are actually important for which amount of our users? As a side note: Mandriva has decided to replace MadWifi with ath5k in the upcoming version 2009 [1]. So they obviously are confident that ath5k is mature enough now for the majority of the Mandriva users... > I believe that ath5k will be much better and that by Christmas with > help from Atheros (we are looking fw for that) it 'll be much better > than current MadWiFi (without support for special stuff like > turbo/dturbo/fastframes/compression for now). What's the status of monitor mode support? AP and IBSS mode? Are there any plans yet to add multi-vap support to mac80211 (I think this is one of the killer features of MadWifi)? > You can't make MadWiFi better but you CAN make ath5k better... Remember: we are not talking of making MadWifi better. The idea instead was (at least back in autumn 2007) to *stabilize* MadWifi in a way that it would work for most users and thus helps to bridge the time until ath5k is more or less up to par. Did we really change this objective? I don't think so, but maybe I'm wrong. However, it seems that we failed to reach this goal so far. And from your description of the status quo of ath5k, we probably should reconsider whether it's worth to continue sticking to this objective. Comments? Bye, Mike [1] http://wiki.mandriva.com/en/2009.0_RC_1#ath5k_replaces_madwifi_for_Atheros_wireless_cards |
From: Nick K. <mic...@gm...> - 2008-09-17 08:05:42
|
2008/9/17 Michael Renzmann <mre...@ma...>: >> I believe that ath5k will be much better and that by Christmas with >> help from Atheros (we are looking fw for that) it 'll be much better >> than current MadWiFi (without support for special stuff like >> turbo/dturbo/fastframes/compression for now). > > What's the status of monitor mode support? AP and IBSS mode? Are there any > plans yet to add multi-vap support to mac80211 (I think this is one of the > killer features of MadWifi)? > 1) Monitor mode works, kismet works, no problem there. You can create a separate monitor interface just like with MadWiFi (check out iw tool, it's like our wlanconfig http://linuxwireless.org/en/users/Documentation/iw). 2) AP mode works but it's under review/testing (Jiri provided a patch some time ago that worked -check this out http://forum.openwrt.org/viewtopic.php?id=16244 - but it needs to be updated due to mac80211 changes, then we need to test it on all hw just to be sure). Have in mind that AP mode is mostly handled by hostapd so you have wpa/acl etc out of the box. 3) I haven't tested IBSS mode for a while but in mac80211 we have 802.11s support so no need to worry about IBSS anymore (mac80211 supports IBSS, ath5k supports it, even if it's broken right now it shouldn't be hard to fix -at least not harder than MadWiFi-). 4) VAPs (multiple SSIDs on the same BSSID) are also handled by hostapd as part of AP support (unfortunately open-source version of hostapd doesn't support that feature yet), mac80211 is ready for this as far as i know (check out AP VLANs) so consider this as work in progress. >> You can't make MadWiFi better but you CAN make ath5k better... > > Remember: we are not talking of making MadWifi better. The idea instead > was (at least back in autumn 2007) to *stabilize* MadWifi in a way that it > would work for most users and thus helps to bridge the time until ath5k is > more or less up to par. > > Did we really change this objective? I don't think so, but maybe I'm > wrong. However, it seems that we failed to reach this goal so far. And > from your description of the status quo of ath5k, we probably should > reconsider whether it's worth to continue sticking to this objective. > > Comments? > > Bye, Mike I think we are wasting resources on trying to stabilize MadWiFi, if team spends more time on ath5k then we 'll have a better solution out there faster. If team keeps trying to stabilize MadWiFi then ath5k will stall and MadWiFi *might* get a little better. I think that if MadWiFi doesn't get any better until December, we should just drop it and focus on ath5k completely. I 'll try to make ath5k much better on the hw part until then so you won't have to worry about this (we 'll have Atheros support also). In general it's much easier to debug a fully open source driver than a semi-open-source driver, problems on ath5k can be fixed much faster than on MadWiFi. Just think about it... -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick |
From: Felix F. <nb...@op...> - 2008-09-17 09:59:33
|
Nick Kossifidis wrote: > I think we are wasting resources on trying to stabilize MadWiFi, if > team spends more time on ath5k then we 'll have a better solution out > there faster. If team keeps trying to stabilize MadWiFi then ath5k > will stall and MadWiFi *might* get a little better. I think that if > MadWiFi doesn't get any better until December, we should just drop it > and focus on ath5k completely. I 'll try to make ath5k much better on > the hw part until then so you won't have to worry about this (we 'll > have Atheros support also). > > In general it's much easier to debug a fully open source driver than a > semi-open-source driver, problems on ath5k can be fixed much faster > than on MadWiFi. Just think about it... I fully agree with Nick on this. Anybody who wants to improve the Atheros driver situation and is not under any kind of agreement that might prevent this should work on ath5k instead of madwifi. I have the OpenWrt version of MadWifi very close to the point where it functions properly as a temporary solution for most people, and I don't want to carry this rotten codebase much further than that. - Felix |
From: Derek S. <de...@in...> - 2008-09-17 15:50:55
|
Hi, This letter was originally posted to the madwifi team list. At Mike's suggestion, I have reposted it here. Apologies for the length of the post, but it is a complex issue. I have been involved in the madwifi code for a number of years now, and trying to use it in adhoc mode. - And use it on nodes that have uptimes of months. Consequently, all my work on the driver has been focussed on adhoc. At various stages, complete frustration has driven me to writing some code for the project. My boss showed me two nodes in his office. "Watch this" he said. In adhoc mode, he manually tweaked the data rate until he achieved an application to application data rate of 20mbit/sec. Then, adhoc again, with the sample rate control algorithm, we measured the application to application data rate. After time to stabilize, the application to application data rate (on the same two nodes) was just 10mbit/sec. Why does the automatic rate control algorithm do so badly he asked? And so I wrote and contributed the minstrel rate control algorithm. How good is the madwifi code we asked for adoc mode? Well, it works on nodes indoors.. So, deployed it outdoors. The TSF in the beacon went to stupidly high numbers - 500 thousand years. At network initialization the beacons from all nodes were "in time" (to borrow a music analogy). Beacons from the network were always detected at some multiple of the beacon interval. Beacons were not sent by a node if some other node had already just sent a beacon. Some days after initialisation, the synchronisation had disappearred.. So - where does the fault lie? Many people have written to various lists around the world and said it is in the HAL/hardware. On reflection though, the HAL/hardware is responsible for sending ack packets sending rts/cts packets sending beacons sending and receiving data packets managing the TSF The content of these packets is determined by the open source code. Indeed, the sending of beacons is initiated by the HAL/hardware. The open source code may elect to suppress the sending of the beacon (radar avoidance). Acks always seem to be sent corectly. Sometimes, there is no transmission or reception of data packets. Is this a HAL/hardware issue, or a driver issue? There is no reliable evidence the HAL/hardware is faulty and the open source code is totally correct. Assertions on the various lists around the world are based on insufficient evidence. A harsher interpretation would say these assertions are based on guesswork, or on the prejudices of the person blaming the HAL. Another check - what is the open source code like? A colleague and I did a code review. The first thing we noticed was a complete lack of design type documents. Which made us wonder about the validity of patches from the different contributor - was every contributor aware of all the constraints/requirements on the driver. Oh well, "Use the source, Luke". We worked in r3314, using openWRT's code base seemed a reasonable option. The code is confusing to follow - multiple questions were asked: How do the methods ieee80211_newstate() and ieee80211_new_state() differ? Well yes, the contents are different, by why use a near identical name? Why is there (seemingly) so much repeated code in ath/if_ath.c ? This file does most of the interraction with the HAL. Methods like ath_reset, ath_init, ath_chan_set are similar in many ways (interrupts off, interrupts on, stop queues, start queues - why is there no common method to do the commonly repeated code blocks? Why does ath_reset() not set the slot time after a reset of the HAL? But these were the easy questions. Why did (after some days) the ping times ramp, as reported in ticket 1154, with associated loss of bandwith (reduced by 80%). Turns out that the only way to stop ramping is to listen to nodes who are configured as being part of our network. (In other words, drastically reduce the number of packets that are processed in ath_recv_mgmt()). This ramping ping time was accurately described by Bruno as a transmission delay issue - the HAL/hardware is for some reason delaying the sending of packets (almost as though it was in power save mode). Then we looked at the receive path of packets. The tasklet that calls ath_recv_mgmt() (as part of the receive process) may have to alter beacon timers, stop start txdma etc because a TSF merge is required. This tasklet will launch a second tasklet if a new node joins our network. But, the second tasklet does a state change (typically RUN->RUN) as a new node has joined our network. This second tasklet will alter HAL parameters, stop start txdma etc also. Why are there two tasklets that run which call similar methods? Where is the locking between the two tasklets? In theory, the first tasklet will be finished before the second tasklet runs. Well, yes, but what happens if a new receive packet comes in, launches the first tasklet again before the second tasklet finishes?? Ouch - it is not clear. some might say, but the tasklets won't interfere cause the kernel does not have preempt on. Is that requirement stated anywhere? And what of SMP boxes ? Argh - not clear. The code and data structures are hideously (and unnecessarily) complex. Which has the result that the code is not maintainable. Sadly, none of us have the brain the size of planet, so fixing the bugs in the current code base is not going to happen. My view Abandon most of the the current open source code as unmaintable. Adopt mac80211 + current HAL + some tiny portion of current code Having a non free component (the HAL) in our code base is not a problem. The major distros provide ways for madwifi to be used in their distros. Sadly, this code will be shortlived, and replaced by ath[59]k Write some documentation on the workings of whatever project is chosen. This will lower the barrier to entry for new developers. If we lower the barrier to entry, new developers can join. This is a must. It is the presence of usable code documentation that distinguishes real projects from wannabe projects. I am happy to write this documentation, once a path forward is chosen. Use current codebase to decipher workings of the HAL/hardware, and push on ath5k-. This will attact developers. This code will live for a long time. The time required to stabilize madwifi is unknown. Is it quicker to stabilize madwifi, or get ath5k up and running? Well, we have been trying to stabilize madwifi for years, and it is not stable/reliable. Given the code state of madwifi, ath[59]k will clearly be ready first. Continuing with the current code - well, honestly, who has the ability/desire to maintain it? This approach can be likened to "rearranging deck chairs on the titanic" [1] Derek. [1] http://idioms.thefreedictionary.com/be+like+rearranging+the+deckchairs+on+the+Titanic -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@in... ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ |
From: Michael R. <mre...@ma...> - 2008-09-17 21:47:05
|
Hi. Felix Fietkau wrote: > I have the OpenWrt version of MadWifi very close to the point where it > functions properly as a temporary solution for most people, and I don't > want to carry this rotten codebase much further than that. Question to all: Would it be an option for us (= the MadWifi project) to replace what we have in trunk with your (OpenWrt) version of MadWifi and make one last release based on that code? This does not say I favour this solution, I'm just trying to learn what others feel about it; it's one of several options we may choose from. Bye, Mike |
From: hiwu.tw <hi...@ms...> - 2008-09-17 23:25:08
|
Hi List: I check the HAL version on FreeBSD release. #define ATH_HAL_VERSION "0.9.14.9" #define ATH_HAL_VERSION "0.9.16.16" #define ATH_HAL_VERSION "0.9.17.2" #define ATH_HAL_VERSION "0.9.20.3" #define ATH_HAL_VERSION "0.10.5.10" Some HALs do not appear on Madwifi Driver. Why FreeBSD and Madwifi use different HAL? Thank you -Jack |
From: Michael R. <mre...@ma...> - 2008-09-18 01:54:45
|
Hi. First of all: please don't reply to an active thread if you want to open a new one instead. hiwu.tw wrote: > Why FreeBSD and Madwifi use different HAL? Because FreeBSD's Atheros driver and MadWifi are different projects. Since Sam has stopped working on MadWifi, both drivers have diverted. We have skipped some of the HALs that Sam released in the past (0.9.20.3 for example, afaict), and we have incorporated others that he has released as CFT ("call for testing", such as 0.10.5.2). Plus it's now considering to eventually switch to the "community HAL" [1]. Bye, Mike [1] http://madwifi.org/wiki/news/20080829/new-hal-release-for-atheros-hardware |
From: p0g0 <p0...@ma...> - 2008-09-16 04:36:46
|
Hi Michael, et al, I've a few thoughts, largely about how to recast the current circumstance into something a bit more attractive than it is now. These are all 'big picture things' and may not appear germane at first glance. There's nothing in here about specific code snippets or the like. I have no quick fixes to offer. When the team made the announcement that madwifi was deprecated, folks figured 1-2 years was a likely time frame for ath5k to mature. New developers were attracted to the true FOSS work of ath5k, and those that remained interested in madwifi development were frequently reminded that their work was ephemeral, with a very short utility life. Time has proven several things: * ath5k is progressing, but 1-2 years is looking pretty unreal for a 'ath5k is as useful and well featured as madwifi' * While Atheros had continued in same basic scheme they'd followed for years, making unsupported code drops, they have also begun to respond to the larger arguments about FOSS (responsibility for FCC & ETSI compliance, etc). They hired one of their largest critics, and iirc, one of the luminaries in FOSS crypto, and that appears to be working well. The two (old style code drops & new FOSS support) are now becoming an auspicious meld, where the ath9k code drop has more support from Atheros than madwifi-ng, but as before, it appears Atheros expects the FOSS community to rework and support that code with only marginal support. * Collaboration is possible: NBD has better co-operation from Sam and Atheros than most folks thought likely. Several organizations have joined up to construct an alternative HAL and free up the bottleneck created by having only Sam Leffler available to work on HALs. * Keeping a team of highly talented volunteers motivated and on track is profoundly challenging. * Few folks have the right mix of RF engineering experience, coding, and temperment to genuinely contribute to the work. So, how to proceed? * I'd suggest taking a very sober look at the time estimates for ath5/9k. I'll argue that the time required to get ath5k up to competitive speed is much longer, and integrating ath9k (which is really more a madwifi-ng+ in terms of it's roots and coding than a derivative of ath5k as the name implies) will take longer yet, even with help from Atheros-they are not intimately familiar with ath5k (yet). If the team can accept that madwifi is not ready for the grave, they should embrace their best estimate of a realistic time frame for it's useful life. If I had to guess, that's more like 2-4 years at least, given the need to debug and certify new code as complicated as 802.11 based stuff has to be. Personally, I am not sure that madwifi ever has to be killed off...if it's not competitive or useful anymore, folks will abandon it themselves, without our help. * Quit trying to couch the ath5|9k codebase vs madwifi as mutually exclusive- I have seen folks argue that they are, but I can find no basis in fact for the notion. When ath5k was launched, we observed new coders joining the team and others reducing their effort or quitting. Confusion and low morale has largely consumed that bubble of coding support afaict. Having both madwifi and athXk could be a collaborative situation, and since you've now experienced the downside of treating the two efforts as competitive and exclusive, I'd encourage those of you hammering the 'madwifi must die' notion to stop. Madwifi may _compete_ with some folks dreams, but that local inconvenience is not a general case, and the consumers of our work can only benefit by having us provide a functional continuum from the old to the new: something that is not happening now. Instead, the team's choice to deprecate madwifi has driven a pretty big stake though the developer's morale and rationale for working on the project. I'd suggest that the team accept and pronounce a policy of mutualism, and state plainly that madwifi and ath5k are not mutually exclusive. * Together, the two points above are making a case for revising the deprecation time-frame, and doing it publicly, and really meaning it. * I'd argue also, that the team and the end-users have suffered from the closed door policy now employed by the team. I can find no valid argument for a FOSS project to operate in secrecy, and I know from my time on the team and since I resigned from it, that the secrecy has kept important information from users, and kept the team from hearing from many folks that have good and important things to say. I think it has also led to hasty and uninformed choices. I'd suggest at least a sunshine policy, where after some delay, the FOSS team's work becomes free available and open to all. However, I think it better yet that all the -team stuff migrates to -devel, and that all of you make an effort to quit with the convenience of secrecy, and instead, be entirely and immediately open in all things madwifi and ath5/9k. The long term benefits outweigh any momentary value of expedient privacy. It's my best guess that making the above repairs is the best path to re-forming the good will and sense of direction needed to attract and reward the volunteers that make madwifi and ath5|9k happen. If that can be accomplished, then all the specific tasks of diffing and merging codebases, testing and addressing bugs, and sculpting the mass of madwifi/ath5|9k code into a functional driver will have a better foundation and a clearer plan for the future. Let's try to make this work, the need for a full featured and supported linux driver for Atheros gear is clear, and no-one but us can make that happen. pax, Will Herrick (p0g0) |
From: Sujith <m.s...@gm...> - 2008-09-16 07:12:54
|
p0g0 wrote: > * While Atheros had continued in same basic scheme they'd followed for > years, making unsupported code drops, they have also begun to respond to > the larger arguments about FOSS (responsibility for FCC & ETSI > compliance, etc). They hired one of their largest critics, and iirc, one > of the luminaries in FOSS crypto, and that appears to be working well. > The two (old style code drops & new FOSS support) are now becoming an > auspicious meld, where the ath9k code drop has more support from Atheros > than madwifi-ng, but as before, it appears Atheros expects the FOSS > community to rework and support that code with only marginal support. Atheros is committed to support ath9k to the fullest extent possible. The driver certainly requires tons of cleanup/rework, but IMO, things are progressing. Sujith |
From: Michael R. <mre...@ma...> - 2008-09-17 02:36:15
|
Hi. p0g0 wrote: > than madwifi-ng, but as before, it appears Atheros expects the FOSS > community to rework and support that code with only marginal support. I disagree. From what I can tell by looking at ath9k-devel it actually seems that most of the work that's been spent on ath9k since it has been published was done by Atheros developers. > * I'd argue also, that the team and the end-users have suffered from > the closed door policy now employed by the team. [...] > However, I think it better yet that all the -team stuff migrates to > -devel, and that all of you make an effort to quit with the > convenience of secrecy, and instead, be entirely and immediately open > in all things madwifi and ath5/9k. [...] Let me explain for those who don't know: We have a non-public mailing list, madwifi-team (or just "-team"). It was established originally to allow private conversation of the team with companies that preferred not to hold such conversation in the public. Atheros was one of those companies, but we were and still are in contact with other companies, too. Over time, that list was used more and more to coordinate the team and hold team-related discussions. At some point we realized that this development is counterproductive, but it still happens that discussions are misplaced there - for example this discussion was started on -team first. Now for your suggestion: I agree that our communication must become open again. However, I disagree about the "migrate madwifi-team to madwifi-devel" part. I'm aware that in the past we had project-related discussions here in madwifi-devel. Back then it was more or less ok, since we took care of only one driver. But things have changed since, we now also have ath5k and ath9k - does that mean we should CC all project-related discussions to ath5k-devel and ath9k-devel, too? The {madwifi,ath5k,ath9k}-devel lists are intended for developer discussion about the corresponding driver, thus discussions about administrative topics on project level are off-topic there. We should have a dedicated mailing list for that, and in fact setting up such a list has been on my to-do-list for two or three months now. The reason why I have not set it up yet basically is the trouble we had (and still have) in terms of the madwifi.org domain: I don't want to add the list over at Sourceforge, but on our own server. The list is about the project, so basing it on the main project domain (madwifi.org) is the natural choice. But the availability of this domain decreased notably during this year due to issues with the authoritative DNS servers; I don't want to elaborate more on that at this time, but will do so in a separate thread soon. We were already working on finding a solution for the domain trouble, so I decided to suspend the "add new mailing list" task for a bit. It took longer than I originally expected, but we now have a solution; it just needs to be implemented, which will happen during the next days. Once this is done I will create a new public mailing list that will be used as public replacement for the private madwifi-team list. (Sorry for being a bit cryptic about the nature of the mentioned solution and timeframe for its implementation - I think people will understand when they read the announcement I will send once the implementation is finished) Bye, Mike |
From: Michael R. <mre...@ma...> - 2008-09-17 04:42:14
|
Hi Will. p0g0 wrote: > * Quit trying to couch the ath5|9k codebase vs madwifi as mutually > exclusive- I have seen folks argue that they are, but I can find no > basis in fact for the notion. The following is my personal point of view, which probably is not shared by other team members. MadWifi suffers from a number of problems which can not easily be resolved. Such as: The driver depends on the binary-only HAL. This was and still is a major pain in the ass. The fact that Felix now actively develops and supports the HAL certainly relieves this a bit, but it's still inconvenient. The codebase is huge, and it largely lacks a proper documentation. Despite the in-source comments it's still pretty hard to get a solid insight into how the driver works internally. Actually I believe we can count the number of people with such insight on one hand (and with the gateway hurdle being set high this probably won't change anytime soon). Which of those people have enough motivation and time left to take care of maintaining the driver? And so on. This situation has not been caused by declaring MadWifi legacy, instead we have to deal with it since the beginning of the project. At the time an alternative (ath5k) became available it made only sense to start thinking about which of the now available roads promise to be less painful mid- and long-term, considering all the pros and cons for each driver. We know the outcome, and I think it would be the same if we did the consideration again today. On a purely technical basis MadWifi and athXk probably are not mutual exclusive; but I think they are as soon as other aspects are taken into account, such as "what resources are required to address the above mentioned problems vs. what resources are available". In other words, IMHO we don't have the resources that are required to properly take care of MadWifi, ath5k and ath9k at the same time, and I don't see that this will change anytime soon. Bye, Mike |
From: Michael R. <mre...@ma...> - 2008-09-16 21:52:20
|
Hi. Kel Modderman wrote: > The development group also seem to function like a dysfunctional family > recently too. Ack. But why is that, and what can we do to change it? Bye, Mike |
From: Kel M. <ke...@ot...> - 2008-09-17 07:51:36
|
On Wednesday 17 September 2008 14:52:16 Michael Renzmann wrote: > Hi. > > Kel Modderman wrote: > > The development group also seem to function like a dysfunctional family > > recently too. > > Ack. But why is that, and what can we do to change it? I honestly do not know why it is like that Mike. What I think could turn it around is strong leadership. However, and I must be careful what I say here, the people who I have in my mind as the most appropriate leaders currently cannot fill this position due to significant reasons of their own. Combine this with the effect a huge stinking pile of bad code has when it comes to attracting smart and motivated hackers, and you get problems. Thanks, Kel. |
From: Luis R. R. <mc...@gm...> - 2008-09-17 21:15:00
|
On Wed, Sep 17, 2008 at 9:59 AM, Felix Fietkau <nb...@op...> wrote: > Nick Kossifidis wrote: >> I think we are wasting resources on trying to stabilize MadWiFi, if >> team spends more time on ath5k then we 'll have a better solution out >> there faster. If team keeps trying to stabilize MadWiFi then ath5k >> will stall and MadWiFi *might* get a little better. I think that if >> MadWiFi doesn't get any better until December, we should just drop it >> and focus on ath5k completely. I 'll try to make ath5k much better on >> the hw part until then so you won't have to worry about this (we 'll >> have Atheros support also). >> >> In general it's much easier to debug a fully open source driver than a >> semi-open-source driver, problems on ath5k can be fixed much faster >> than on MadWiFi. Just think about it... > I fully agree with Nick on this. Anybody who wants to improve the > Atheros driver situation and is not under any kind of agreement that might > prevent this should work on ath5k instead of madwifi. > I have the OpenWrt version of MadWifi very close to the point where it > functions properly as a temporary solution for most people, and I don't > want to carry this rotten codebase much further than that. I agree here as well but let me try to clarify why and be as clear as I can be, and I'll try to keep it short too. MadWifi has long been dead for me, I hate it with a passion and that is the only reason why I got involved with it -- to help kill it and stab it to death with an open alternative upstream. MadWifi was always just the wrong solution to proper Linux support and always will be. In fact back when I worked on other wireless drivers I swore to myself I would never work on MadWifi, it was only due to the *need* to support Orbit that I got involved with it but the number mysteries around strange hardware issues and number of WTF's / second were just too high so I jumped on Nick's port of OpenBSD's ar5k to Linux and immediately started focusing attention on that. You can keep on working on MadWIfi and I respect that, but I personally just will never pay attention to it, and I would encourage developers should completely dedicate their attention on the open drivers we have. To me any effort spent on MadWifi at this point is just an effort in keeping a huge ugly monster alive, the code is essentially going into a blackhole that will be *thrown away* soon. I understand users which have no hardware support will have to use it, and this is why we also have been considering supporting work on ath5k. In the end *we will work with ath5k* and my hopes are that by 2.6.29 ath5k will be obviously > madwifi. I think we missed the merge window for 2.6.28, we'll see, but I think so. So yeah this might be by Christmas. compat-wireless is still around though so users can still benefit from development advancements going on in wireless-testing. We will provide more details hopefully by the end of next week. So, die MadWifi, die! Bleeeeed! :D Luis |
From: Michael R. <mre...@ma...> - 2008-09-17 21:40:00
|
Hi Luis. Since you write with your gmail e-mail address here, let me ask for clarification: Luis R. Rodriguez wrote: > [...] In the end *we will work with ath5k* [...] > [...] We will provide more details hopefully by the end of next week. [...] Does "we" refer to "Atheros" in these cases? Bye, Mike |
From: Luis R. R. <mc...@gm...> - 2008-09-17 21:49:50
|
On Wed, Sep 17, 2008 at 9:39 PM, Michael Renzmann <mre...@ma...> wrote: > Hi Luis. > > Since you write with your gmail e-mail address here, let me ask for > clarification: > > Luis R. Rodriguez wrote: >> [...] In the end *we will work with ath5k* [...] >> [...] We will provide more details hopefully by the end of next week. [...] > > Does "we" refer to "Atheros" in these cases? Yes. Luis |
From: Achim 'a. F. <mai...@ah...> - 2008-09-29 12:38:52
|
Michael Renzmann schrieb: > > The driver depends on the binary-only HAL. This situation changed during the last days as Atheros released the source of the 0.9.17.1 HAL ( http://lwn.net/Articles/300758/ ) So will this help to improve the situation of the madwifi driver in the near future? achim |
From: Felix F. <nb...@op...> - 2008-09-29 12:53:39
|
Achim 'ahzf' Friedland wrote: > Michael Renzmann schrieb: >> >> The driver depends on the binary-only HAL. > > This situation changed during the last days as Atheros released the > source of the 0.9.17.1 HAL ( http://lwn.net/Articles/300758/ ) > > So will this help to improve the situation of the madwifi driver in the > near future? I don't think this HAL will get ported to MadWiFi - too much work and simply not worth it. It serves mostly to help ath5k. - Felix |
From: Michael R. <mre...@ma...> - 2008-09-29 13:51:51
|
Hi. Achim 'ahzf' Friedland wrote: > So will this help to improve the situation of the madwifi driver in the > near future? I only speak for myself here: I don't think so. While it might help MadWifi to loose its "non-free" status, many other issues will remain intact. Among them being "lack of documentation for developers", "dependency on third-party 802.11 stack" and "hardly manageable codebase". Bye, Mike |
From: Georg L. <ge...@bo...> - 2008-09-29 12:48:24
|
Hello, * Achim 'ahzf' Friedland <mai...@ah...> [2008-09-29 14:43]: > > The driver depends on the binary-only HAL. > This situation changed during the last days as Atheros released the > source of the 0.9.17.1 HAL ( http://lwn.net/Articles/300758/ ) > > So will this help to improve the situation of the madwifi driver in the > near future? Not for madwifi. The released HAL is only a subset of the code (AR5212 only) and it is not the same HAL as used by MadWifi. I think there is no direct way of integrating it into the MadWifi codebase, and neither a use for that. It will however greatly improve the development possibilities for ath5k, which is good too. Georg -- || http://op-co.de ++ GCS/CM d? s: a-- C+++ UL+++ !P L+++ E--- W++ ++ || gpg: 0x962FD2DE || N++ o? K- w---() O M V? PS+ PE-- Y+ PGP++ t* || || Ge0rG: euIRCnet || 5 X+ R tv b+(+++) DI+(+++) D+ G e* h! r* !y+ || ++ IRCnet OFTC OPN ||________________________________________________|| |