On Tue, Nov 17, 2009 at 9:51 AM, Tom Sharples <tsharples@xxxxxxxxxx> wrote: > Comments inline: >> >> My point was that there are already hundreds of users already on ath5k >> and ath9k and that obviously you will get a biased view of MadWifi / >> ath5k situation (I don't consider MadWifi any type of alternative to >> ath9k). > > We have way more users than this running just our version. There are > probably tens of thousands of "users" (embedded systems) that run some > flavor of madwifi. Haha are you really trying to out count modern Linux kernel users with MadWifi embedded users? >>> The development of any software should happen with the user's needs and >>> requirements in mind >> >> Note I didn't say otherwise. > > Your comments, at best, give short shrift to the many, many embedded users, > esp those who run the 2.4.x kernel. Does anyone actually think it would be > practical to remotely upgrade tens of thousands of unattended devices, some > of which are miles away from the nearest human, to a 2.6 kernel? What do you expect to get out of MadWifi at this point if not just maintenance mode support for that box you cannot even upgrade a full kernel on that is miles away from any human being? > Even if > only 5% fail to come back online, it would be a logistical and > customer-relations disaster. These aren't windows desktops where someone can > just curse and then powercycle. You can perfectly stick to what you have, like I said no one is forcing you to do anything different, but failing to understand that MadWifi development has come to a stand still maintenance mode would be just as ludicrous as expecting you to upgrade every single box you have out there. >> Well to me they are clear and I don't need a survey to understand >> this. ath5k currently lacks: >> >> * DFS >> * Multi-BSS AP functionality >> * Roaming >> * ANI >> > You also need to add to this list: > > * Fast-frames > * Compression Not sure if the above are vendor extensions, if so and if they require some tweaking on mac8021 chances are you won't get them upstream. > * Half / quarter channels (hopefully done in a sensible fashion like AirOS > without the countrycode / regdomain BS) As far as its supported by IEEE this seems reasonable, you just need motivated developers. > We need to aknowledge that "user" includes not just those surfing on their > laptops, but the far larger number of embedded devices running madwifi each > and every day, in critical systems, with excellent reliability. Sure, but just as with MadWifi if you don't have embedded interested developers on MadWifi you won't get them on ath5k. What should also be realized though is that not every single knob and feature of MadWifi will make it upstream. Anything vendor specific or hackish will simply not make it up -- unless you really have a motivated developer willing to support it. Luis -- 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
