Re: [Madwifi-devel] Survey: What are you using MadWifi for, and why?

Re: [Madwifi-devel] Survey: What are you using MadWifi for, and why?

[Luis R. Rodriguez]

On Sun, Nov 15, 2009 at 2:52 AM, Michael Renzmann
<mrenzmann@madwifi-project.org> wrote:
> Hi all.
>
> As you might have noticed, there currently is a discussion [1] going on
> about the future directions of the MadWifi project, including a decision
> how to deal with MadWifi driver. It turns out that there are pretty
> contrary positions in this regard: some would like to see MadWifi being
> dumped completely as soon as possible, others would prefer to continue
> development and even implement new features.
>
> What do others think? It appears to me that we know too little about what
> MadWifi is actually used for today and why. Thus I'd like to start a quick
> survey.
>
> It would be great if you could answer some or - ideally - all of the
> following questions:
>
>  1. What are you using MadWifi for?
>
>  2. Did you already evaluate ath5k/ath9k? If no, why not?
>
>  3. In case you evaluated ath5k/ath9k but did not yet switch: what is the
> reason for your decision, and what is required before you could switch?
>
> Any input is highly welcome, thanks in advance for your time.
>
> Bye, Mike
>
> [1] http://thread.gmane.org/gmane.linux.drivers.madwifi.project/165
>

Everyone on kernels >= 2.6.25 would have tried ath5k, granted with
probably a horrible experience as it was still early development.

Everyone on >= 2.6.27 would have tried ath9k.

So some sort of survey on this on madwifi-devel is not fair or just to
ath5k/ath9k as the only thing it would bring out is those romantics
still reading madwifi-devel due to some sort of attachment to it. I'm
not saying those attachments are bad I'm just saying MadWifi is long
dead to many and those still reading to madwifi lists are obviously
still trying to use it for one reason or another.

Madwifi's future as a Linux driver does not depend on what users wish
would happen on a legacy driver due to romantic experiences with it
with extensive features and its history. From a development
perspective the future of any Linux driver is just to go upstream. Its
very simple. Any company developing a driver out-of-tree is just not
doing Linux driver development the right way.

Linux distributions won't go around carrying legacy drivers unless
they serve a purpose and what you'll see is Linux distributions prefer
upstream drivers for an obvious reason -- its where Linux drivers
should go.

If a few developers still exist who are committed to helping maintain
madwifi until ath5k gets feature-parred the easiest solution now
(since the HAL is open) is to just throw it into staging and hopefully
that'll attract more developers to help keep it up to date with actual
current kernels. No -- you won't get 2.4 kernel support though -- if
you're on 2.4 you should just upgrade. But really best thing as a user
or motivated developer is to just annotate a missing feature and add
it upstream through mac80211/cfg80211 as ath5k really should be in a
decent condition by current kernel standards and Madwifi as a codebase
can probably just remain in maintenance mode outside of the kernel.

Anything else is just wasting time and electrons.

  Luis

Re: [Madwifi-devel] Survey: What are you using MadWifi for, and why?

[John W. Linville]

On Mon, Nov 16, 2009 at 05:01:09PM -0800, Luis R. Rodriguez wrote:

> If a few developers still exist who are committed to helping maintain
> madwifi until ath5k gets feature-parred the easiest solution now
> (since the HAL is open) is to just throw it into staging and hopefully
> that'll attract more developers to help keep it up to date with actual
> current kernels.

For the record, I would be generally opposed to adding madwifi to
drivers/staging.  We already have enough trouble with duplication of
hardware support between drivers/staging and drivers/net/wireless.

If madwifi has features that people need/want and that ath5k/mac80211
still lacks, lets talk about how to get them (or reasonabe replacements
for them) into the mainline kernel.  I'm sure some ideas will meet
some resistance, but if someone is motivated to continue pursuing
maintenance of madwifi than they should be motivated enough to at
least try to convince the rest of us why those features are worth
having in net/wireless, net/mac80211, and/or drivers/net/wireless.
Even if the solution is some quirky thing that "normal" people will
ignore, it is bound to be better to have mainline support than to
continue working out-of-tree.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [Madwifi-devel] Survey: What are you using MadWifi for, and why?

[Marcel Holtmann]

Hi John,

> > If a few developers still exist who are committed to helping maintain
> > madwifi until ath5k gets feature-parred the easiest solution now
> > (since the HAL is open) is to just throw it into staging and hopefully
> > that'll attract more developers to help keep it up to date with actual
> > current kernels.
> 
> For the record, I would be generally opposed to adding madwifi to
> drivers/staging.  We already have enough trouble with duplication of
> hardware support between drivers/staging and drivers/net/wireless.
> 
> If madwifi has features that people need/want and that ath5k/mac80211
> still lacks, lets talk about how to get them (or reasonabe replacements
> for them) into the mainline kernel.  I'm sure some ideas will meet
> some resistance, but if someone is motivated to continue pursuing
> maintenance of madwifi than they should be motivated enough to at
> least try to convince the rest of us why those features are worth
> having in net/wireless, net/mac80211, and/or drivers/net/wireless.
> Even if the solution is some quirky thing that "normal" people will
> ignore, it is bound to be better to have mainline support than to
> continue working out-of-tree.

I 100% agree with you. The MadWifi driver should NOT be included into
the staging tree. We have an upstream driver for this hardware and if
people are not happy with it, then they should start fixing or extending
it. A second driver for the same hardware just causes confusion.

Regards

Marcel