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.
>>
>> 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? 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.
>
> 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
* Half / quarter channels (hopefully done in a sensible fashion like AirOS
without the countrycode / regdomain BS)
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.
Tom S.
On Tue, Nov 17, 2009 at 9:51 AM, Tom Sharples <[email protected]> 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