lkml.org 
[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [madwifi-project] [RFC] Closing the project
Luis R. Rodriguez wrote:
> On Wed, Nov 12, 2008 at 7:31 PM, Pavel Roskin <proski@gnu.org> 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 majordomo@vger.kernel.org
> 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)




\
 
 \ /
  Last update: 2008-11-13 21:23    [W:0.065 / U:5.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site