Re: [Madwifi-users] [Madwifi-devel] Survey: What are you using MadWifi for, and why?
Status: Beta
Brought to you by:
otaku
From: David G. <dav...@bt...> - 2009-11-17 19:56:10
|
On Tuesday 17 November 2009, Luis R. Rodriguez wrote: > On Tue, Nov 17, 2009 at 9:51 AM, Tom Sharples <tsh...@qo...> 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 > > --------------------------------------------------------------------------- > --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - > and focus on what you do best, core application coding. Discover what's > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > Luis, I think in this answer you answered the question as to why some people use MadWifi rather than athXk - ignoring people stuck on old kernels. The answer is in large part that they want the bits that are not in the standards and therefore will never make it into the kernel. Why do they want then, because they solve a problem; why are they not part of the standards, because the orgainizing committee did not think of them. My guess is that if enough people work on these extensions and show that they are useful then it is just possible that they will be recognised by said committee and be included. But if course if they do not get the chance because nothing that has not come from the committee is allowed then no progress! In short if athXk (and the common code) allowed extensions, and provided a means for them to be added the future need for madwifi might be minimal. But if the extensions are continually rejected then madwifi will continue and frankly whether it is ever included in the mainline kernel is irrelevant. David |