On Wed, Nov 12, 2008 at 7:31 PM, Pavel Roskin <[email protected]> wrote:
> On Wed, 2008-11-12 at 12:24 -0800, Luis R. Rodriguez wrote:
>
>> Those who are interested in this should work on it if no one else is,
>> just take it and go. Bureaucracy gets in the way here IMHO.
>
> It's not about bureaucracy. I need help with porting the code from one
> branch to another. In particular, with fixing SMP locking issues in the
> 0.9.4 branch. The trunk doesn't have those issues.
If you are not getting help its because there is a lack of interest
from developers. I expected this once ath5k got upstream and once more
documentation was available.
>> Distributions will soon prefer ath5k over MadWifi. At that point
>> MadWifi becomes a relic. Its surely good to keep MadWifi code
>> somewhere for reference, or maybe for the last few devices maybe not
>> yet supported, but any other effort put into seems like fruitless
>> effort spent IMHO.
>
> As far as I know, we don't have DFS in mac80211. In fact, the AP mode
> in mac80211 has just been enabled.
Right, more notes on this below.
>> I don't have experience with bounties but I do know I get random
>> requests to support one thing or another for money. I am going to be
>> redirecting these request more to bounties put up for upstream
>> development. I know people will work on things anyway but what I want
>> to try to do is get monetary support one way or another to those
>> working upstream.
>
> OK, let's consider it on the case-by-case basis.
Well I'm just going to direct people towards bounties myself for
upstream work. That's the advice I will be giving personally. But I do
think it would be good for the project to also reward upstream work
too, wasn't that the whole point behind the project?
>> I'd like to encourage the money left for the project for similar
>> purposes. Reward upstream development.
>
> Maybe we could have a bounty for DFS implementation in mac80211? Just
> to try how it would work. I also this that there should be a strong
> moral incentive for the winner. Not just a name in the log, but a web
> page about the winner on kernel.org. This way, we would attract people
> striving to improve their resumes, not just get extra money.
We will be working on DFS on mac80211, I will start first with STA
DFS. Also expect a lot of work from us on AP support.
>> I think MadWifi has become a big bureaucratic entity and this large
>> bureaucracy is simply not needed.
>
> I agree that we have a lot of documentation that is becoming irrelevant.
> I prefer to keep documentation to the minimum, as it stimulates
> developers to write software that just works, without lengthy
> instructions.
>
> But the bug tracking system has some important information that we still
> may need.
>
> I think the biggest impediment to MadWifi development was not
> bureaucracy. It was the non-free HAL.
Not really, even with an alternative people are still used to coding
with it and find it easier to commit into an svn repository than
submit patches upstream. Maybe our process is move involved but there
its also why Linux code has a certain quality in it. We tend to frown
upon crap. If MadWifi ever were to touch Linux it would be tainted
with CRAP.
> Many bugs are too hard or
> impossible to solve without having access to HAL. As the easy bugs get
> fixed, the ratio of HAL-related bugs grows further.
>
> We have HAL sources, but it's not the sources we could use in Madwifi
> without losing some functionality. Sure enough, the HAL sources could
> help with some issues. But it's still impossible to put debug
> statements into the HAL uses in MadWifi.
>
> I'm thinking of having "MadWifi free edition" with limited hardware
> support specifically to address the issue of "debuggability". Also,
> some users may free code plus MadWifi features.
I really think this is good for those interested and I respect it but
I am going to be very very honest here: this is a complete fucking
waste of time. People, MadWifi is dead, stop trying to keep it a live
by injecting its heart with adrenaline, it won't work, just pull the
plug already. If any feature is missing I think it would be more
productive to identify it and point it out and those interested in
upstream work will add it.
> Some users may want
> support for exotic CPUs not supported by any non-free HAL.
For that you can use the Linux kernel which will get you support on
the largest number of CPUs possible.
>> We wanted free drivers, we have them
>> now, we have opened up the HAL and have even opened up more drivers
>> and continue to do so. What I find useful from MadWifi from an
>> upstream perspective is the mailing lists and a central place for
>> people to get information/news regarding Atheros devices supported
>> upstream but I guess we can just keep this in the wireless wiki.
>
> I agree that it's better to start anew with the documentation for the
> free drivers.
>
>> Mailing lists are pretty useful though.
>
> Yes.
>
>> I agree there is some useful information present but a lot of it is
>> purely historical and I don't think much resources is needed to keep
>> that around. I suspect distributions will start preferring ath5k over
>> MadWifi around December if not already so I'm indifferent in closing
>> MadWifi. In my head MadWifi is dead already though and would recommend
>> we only promise users it will be in maintenance mode, meaning the
>> MadWifi driver will only get submitted bug fixes and security fixes.
>
> I agree with you. We should fix the code already in MadWifi branches.
> It means we should not be _closing_ the project now.
Just my advice: let MadWifi die already, stop wasting your time.
Luis
Luis R. Rodriguez wrote:
> On Wed, Nov 12, 2008 at 7:31 PM, Pavel Roskin <[email protected]> wrote:
>> On Wed, 2008-11-12 at 12:24 -0800, Luis R. Rodriguez wrote:
>>
>>> Those who are interested in this should work on it if no one else is,
>>> just take it and go. Bureaucracy gets in the way here IMHO.
>> It's not about bureaucracy. I need help with porting the code from one
>> branch to another. In particular, with fixing SMP locking issues in the
>> 0.9.4 branch. The trunk doesn't have those issues.
>
> If you are not getting help its because there is a lack of interest
> from developers. I expected this once ath5k got upstream and once more
> documentation was available.
>
>>> Distributions will soon prefer ath5k over MadWifi. At that point
>>> MadWifi becomes a relic. Its surely good to keep MadWifi code
>>> somewhere for reference, or maybe for the last few devices maybe not
>>> yet supported, but any other effort put into seems like fruitless
>>> effort spent IMHO.
>> As far as I know, we don't have DFS in mac80211. In fact, the AP mode
>> in mac80211 has just been enabled.
>
> Right, more notes on this below.
>
>>> I don't have experience with bounties but I do know I get random
>>> requests to support one thing or another for money. I am going to be
>>> redirecting these request more to bounties put up for upstream
>>> development. I know people will work on things anyway but what I want
>>> to try to do is get monetary support one way or another to those
>>> working upstream.
>> OK, let's consider it on the case-by-case basis.
>
> Well I'm just going to direct people towards bounties myself for
> upstream work. That's the advice I will be giving personally. But I do
> think it would be good for the project to also reward upstream work
> too, wasn't that the whole point behind the project?
>
>>> I'd like to encourage the money left for the project for similar
>>> purposes. Reward upstream development.
>> Maybe we could have a bounty for DFS implementation in mac80211? Just
>> to try how it would work. I also this that there should be a strong
>> moral incentive for the winner. Not just a name in the log, but a web
>> page about the winner on kernel.org. This way, we would attract people
>> striving to improve their resumes, not just get extra money.
>
> We will be working on DFS on mac80211, I will start first with STA
> DFS. Also expect a lot of work from us on AP support.
>
>>> I think MadWifi has become a big bureaucratic entity and this large
>>> bureaucracy is simply not needed.
>> I agree that we have a lot of documentation that is becoming irrelevant.
>> I prefer to keep documentation to the minimum, as it stimulates
>> developers to write software that just works, without lengthy
>> instructions.
>>
>> But the bug tracking system has some important information that we still
>> may need.
>>
>> I think the biggest impediment to MadWifi development was not
>> bureaucracy. It was the non-free HAL.
>
> Not really, even with an alternative people are still used to coding
> with it and find it easier to commit into an svn repository than
> submit patches upstream. Maybe our process is move involved but there
> its also why Linux code has a certain quality in it. We tend to frown
> upon crap. If MadWifi ever were to touch Linux it would be tainted
> with CRAP.
>
>> Many bugs are too hard or
>> impossible to solve without having access to HAL. As the easy bugs get
>> fixed, the ratio of HAL-related bugs grows further.
>>
>> We have HAL sources, but it's not the sources we could use in Madwifi
>> without losing some functionality. Sure enough, the HAL sources could
>> help with some issues. But it's still impossible to put debug
>> statements into the HAL uses in MadWifi.
>>
>> I'm thinking of having "MadWifi free edition" with limited hardware
>> support specifically to address the issue of "debuggability". Also,
>> some users may free code plus MadWifi features.
>
> I really think this is good for those interested and I respect it but
> I am going to be very very honest here: this is a complete fucking
> waste of time. People, MadWifi is dead, stop trying to keep it a live
> by injecting its heart with adrenaline, it won't work, just pull the
> plug already. If any feature is missing I think it would be more
> productive to identify it and point it out and those interested in
> upstream work will add it.
>
>> Some users may want
>> support for exotic CPUs not supported by any non-free HAL.
>
> For that you can use the Linux kernel which will get you support on
> the largest number of CPUs possible.
>
>>> We wanted free drivers, we have them
>>> now, we have opened up the HAL and have even opened up more drivers
>>> and continue to do so. What I find useful from MadWifi from an
>>> upstream perspective is the mailing lists and a central place for
>>> people to get information/news regarding Atheros devices supported
>>> upstream but I guess we can just keep this in the wireless wiki.
>> I agree that it's better to start anew with the documentation for the
>> free drivers.
>>
>>> Mailing lists are pretty useful though.
>> Yes.
>>
>>> I agree there is some useful information present but a lot of it is
>>> purely historical and I don't think much resources is needed to keep
>>> that around. I suspect distributions will start preferring ath5k over
>>> MadWifi around December if not already so I'm indifferent in closing
>>> MadWifi. In my head MadWifi is dead already though and would recommend
>>> we only promise users it will be in maintenance mode, meaning the
>>> MadWifi driver will only get submitted bug fixes and security fixes.
>> I agree with you. We should fix the code already in MadWifi branches.
>> It means we should not be _closing_ the project now.
>
> Just my advice: let MadWifi die already, stop wasting your time.
Yeah but ath5k doesn't work on my zyxel ar5212 based wireless card only
madwifi works!
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Thu, Nov 13, 2008 at 12:21 PM, Stephen Clark <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> Just my advice: let MadWifi die already, stop wasting your time.
>
> Yeah but ath5k doesn't work on my zyxel ar5212 based wireless card only
> madwifi works!
The discussion is about further pushing MadWifi vs keeping it in only
maintenance mode. In your case the code would still exist until ath5k
make it work appropriately.
Also -- what kernel have you tried ath5k on that it does not work on?
Have you tried compat-wireless? Keep in mind to use the latest you'll
need at least 2.6.27 installed.
Luis
On Thu, 2008-11-13 at 11:42 -0800, Luis R. Rodriguez wrote:
> We will be working on DFS on mac80211, I will start first with STA
> DFS. Also expect a lot of work from us on AP support.
That's great news!
> >> I think MadWifi has become a big bureaucratic entity and this large
> >> bureaucracy is simply not needed.
> >
> > I agree that we have a lot of documentation that is becoming irrelevant.
> > I prefer to keep documentation to the minimum, as it stimulates
> > developers to write software that just works, without lengthy
> > instructions.
> >
> > But the bug tracking system has some important information that we still
> > may need.
> >
> > I think the biggest impediment to MadWifi development was not
> > bureaucracy. It was the non-free HAL.
>
> Not really, even with an alternative people are still used to coding
> with it and find it easier to commit into an svn repository than
> submit patches upstream. Maybe our process is move involved but there
> its also why Linux code has a certain quality in it. We tend to frown
> upon crap. If MadWifi ever were to touch Linux it would be tainted
> with CRAP.
OK, HAL was not the only reason. Let's say there is good bureaucracy
and bad bureaucracy. The difference is the former is helpful and the
later is not. The kernel is an excellent example of good bureaucracy
that we should learn from.
It would be great to have a detailed analysis why MadWifi failed. It
would be useful for other projects. I'm short on time to do it right
now, but I may do it later.
I think we should have done more to prevent incomplete or broken changes
from being committed. The reason I cannot backport SMP fixes is because
they were committed as series of commits that involved other issues as
well. Such sloppiness should have been prevented.
> Just my advice: let MadWifi die already, stop wasting your time.
I understand what you mean, but I have to deal with MadWifi anyway. As
I said before, I'd rather share my fixes that keep them to myself.
--
Regards,
Pavel Roskin
On Thu, Nov 13, 2008 at 12:48 PM, Pavel Roskin <[email protected]> wrote:
> On Thu, 2008-11-13 at 11:42 -0800, Luis R. Rodriguez wrote:
>
>> > I think the biggest impediment to MadWifi development was not
>> > bureaucracy. It was the non-free HAL.
>>
>> Not really, even with an alternative people are still used to coding
>> with it and find it easier to commit into an svn repository than
>> submit patches upstream. Maybe our process is move involved but there
>> its also why Linux code has a certain quality in it. We tend to frown
>> upon crap. If MadWifi ever were to touch Linux it would be tainted
>> with CRAP.
>
> OK, HAL was not the only reason. Let's say there is good bureaucracy
> and bad bureaucracy. The difference is the former is helpful and the
> later is not. The kernel is an excellent example of good bureaucracy
> that we should learn from.
>
> It would be great to have a detailed analysis why MadWifi failed.
It didn't fail, it was just not the best approach to support Linux
from the start, that's why *today* its just silly to go on with it,
specially since the vendor involved is *contributing* and helping to
implement support the right way.
>> Just my advice: let MadWifi die already, stop wasting your time.
>
> I understand what you mean, but I have to deal with MadWifi anyway. As
> I said before, I'd rather share my fixes that keep them to myself.
Understood -- but perhaps you can identify what is lacking that you
need to better help push what is required and missing.
Luis
On Thu, 2008-11-13 at 12:54 -0800, Luis R. Rodriguez wrote:
> On Thu, Nov 13, 2008 at 12:48 PM, Pavel Roskin <[email protected]> wrote:
> > It would be great to have a detailed analysis why MadWifi failed.
>
> It didn't fail, it was just not the best approach to support Linux
> from the start, that's why *today* its just silly to go on with it,
> specially since the vendor involved is *contributing* and helping to
> implement support the right way.
OK, I mean MadWifi failed to deliver what it could have delivered. It
failed to improve the code significantly. It failed to deal with the
bugs that could have been fixed. It failed to release the code that was
written by the team members. It failed to stabilize.
> >> Just my advice: let MadWifi die already, stop wasting your time.
> >
> > I understand what you mean, but I have to deal with MadWifi anyway. As
> > I said before, I'd rather share my fixes that keep them to myself.
>
> Understood -- but perhaps you can identify what is lacking that you
> need to better help push what is required and missing.
Specifically for me - just three letters. DFS.
--
Regards,
Pavel Roskin
On Thu, 13 Nov 2008, Pavel Roskin wrote:
> On Thu, 2008-11-13 at 12:54 -0800, Luis R. Rodriguez wrote:
>> On Thu, Nov 13, 2008 at 12:48 PM, Pavel Roskin <[email protected]> wrote:
>>>> Just my advice: let MadWifi die already, stop wasting your time.
Good advise.
> Specifically for me - just three letters. DFS.
Why are you worried about DFS?
There is only one feature that is important:
Reliability. It has to work for months, without rebooting.
Consider a very reasonable use of madwifi - in a linux router. It has to
work reliably - without being rebooted by the user.
Consider an AP box that had madwifi in it. Every couple of days, the user
has to reboot it to get the box to work again. The user gets upset and
returns the box. This is not a commercial product. Yes, the box did DFS,
but it had to be rebooted regularly.
While the DFS is nice - it is not reliable.
Now - you have noticed the comments about SMP issues in this thread.
Do you know what that implies? There are races races races in the code.
There are contention issues. What is the only reliable fix for SMP?
complete redesign. Pull the code apart - and work out what each tasklet
and interrupt does. Ensure there is no contention.
Have you noticed the long standing bugs in the bug tracker? Stuck beacon,
ping ramping in adhoc. Do you know why these bugs are long standing?
Cause noone has the skill/ability/knowledge to fix them. ((Sure, there is
a purported fix for ping ramping - but this fixes the symptom, not
cause)). I have a fix for ping ramping - it required a complete redesign
of the codebase. I can report it, and give you the code, but you cannot
use it in madwifi cause it breaks wds, scanning, dfs, ap, sta modes.
The options are clear::
a)Fix stabilise madwifi
or
b)add features to mac80211
a is a lot of work in a short lived project
b is a lot of work in a project that is going to be around for years.
===================================
Sure, if we abandon development on madwifi - we are breaking our promise.
Given the current rate of development, we will not be able to provide a
stable reliable code base with DFS etc in the promised timescale. thus, if
we continue developing madwifi, we will fail to meet objective, and end up
breaking our promise in the future.
Conclusion:: break the promise now, or later.
As an end user of madwifi, it is more reasonable to break the promise now.
I end up being forced to agree with Luis:
>>>> Just my advice: let MadWifi die already, stop wasting your time.
Derek.
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: [email protected]
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/