Thread: [Madwifi-devel] How many active developers of madwifi is there?
Status: Beta
Brought to you by:
otaku
From: N.Leiten <nic...@gm...> - 2010-03-26 10:01:43
|
Well, it is the question itself. How many active developers are maintaining madwifi? The question is about to continue development due to lack of support and progress with mac80211 in mainline kernel itself. And due to interest from phd and research groups to madwifi and same interest to net80211 bsd-stack from companies like intel, ubiquity - it becomes obvious that project needs more care than it have now. While some code revise i'm noticed that some work needed to solve old problems and architecture defects to make madwifi become the best alternative. Some thoughts about net80211 and hal - maybe we have to revise code to be more bsd-compatible, so future code porting will be easier and take less time to work. Also have some thoughts about protocol enhancements, but with mac80211 it is unable to stay clear about API structure to maintain and develop them. I'm suggesting do 80211-independent work with such enhancements, so it will be possible to port to mac80211, net80211 and other softmac realizations, but for primer work - use madwifi. Regards. |
From: Pavel R. <pr...@gn...> - 2010-03-26 21:22:36
|
On Fri, 2010-03-26 at 12:01 +0200, N.Leiten wrote: > Well, it is the question itself. > How many active developers are maintaining madwifi? I believe I'm the only one who committed any changes to MadWifi lately. But to call it "maintaining" would be an overstatement. > The question is about to continue development due to lack of support and > progress with mac80211 in mainline kernel itself. I'm sorry, it's hard for me to understand you. Are you saying that mac80211 is not developed? I think the opposite is true. > And due to interest from phd > and research groups to madwifi and same interest to net80211 bsd-stack from > companies like intel, ubiquity - it becomes obvious that project needs more > care than it have now. I don't know about Intel. As for Ubiquiti, I think they simply preferred to make their HAL for MadWifi because MadWifi provided a ready infrastructure for incorporating non-free code in a binary form. It's actually an argument _against_ maintaining MadWifi, as Ubiquiti would be forced to work with ath5k and ath9k if MadWifi was totally obsolete and buggy. > While some code revise i'm noticed that some work needed to solve old problems > and architecture defects to make madwifi become the best alternative. > Some thoughts about net80211 and hal - maybe we have to revise code to be more > bsd-compatible, so future code porting will be easier and take less time to > work. I would be fine with that. When the HAL sources were released, MadWifi could use them with minimal changes. After the channel API was changed, it's no longer possible to track all HAL changes in FreeBSD. However, I don't want massive changes to the MadWifi codebase, especially if they are hard to verify. We have few users and nobody is actively monitoring new bugs in the bug tracker. The risk is to break something and never hear about it from the users. > Also have some thoughts about protocol enhancements, but with mac80211 it is > unable to stay clear about API structure to maintain and develop them. I'm > suggesting do 80211-independent work with such enhancements, so it will be > possible to port to mac80211, net80211 and other softmac realizations, but for > primer work - use madwifi. I used MadWifi to experiment with using kernel CCM encryption. MadWifi was more convenient because it has a testsuite for CCMP. But generally, I think we should try to make mac80211 suitable for everything, including prototyping of new protocols. -- Regards, Pavel Roskin |
From: N.Leiten <nic...@gm...> - 2010-03-27 07:27:28
|
В сообщении от Пятница 26 марта 2010 23:22:29 автор Pavel Roskin написал: > On Fri, 2010-03-26 at 12:01 +0200, N.Leiten wrote: > > Well, it is the question itself. > > How many active developers are maintaining madwifi? > > I believe I'm the only one who committed any changes to MadWifi lately. > But to call it "maintaining" would be an overstatement. > > > The question is about to continue development due to lack of support and > > progress with mac80211 in mainline kernel itself. > > I'm sorry, it's hard for me to understand you. Are you saying that > mac80211 is not developed? I think the opposite is true. > > > And due to interest from phd > > and research groups to madwifi and same interest to net80211 bsd-stack > > from companies like intel, ubiquity - it becomes obvious that project > > needs more care than it have now. > > I don't know about Intel. As for Ubiquiti, I think they simply > preferred to make their HAL for MadWifi because MadWifi provided a ready > infrastructure for incorporating non-free code in a binary form. It's > actually an argument _against_ maintaining MadWifi, as Ubiquiti would be > forced to work with ath5k and ath9k if MadWifi was totally obsolete and > buggy. > > > While some code revise i'm noticed that some work needed to solve old > > problems and architecture defects to make madwifi become the best > > alternative. Some thoughts about net80211 and hal - maybe we have to > > revise code to be more bsd-compatible, so future code porting will be > > easier and take less time to work. > > I would be fine with that. When the HAL sources were released, MadWifi > could use them with minimal changes. After the channel API was changed, > it's no longer possible to track all HAL changes in FreeBSD. > > However, I don't want massive changes to the MadWifi codebase, > especially if they are hard to verify. We have few users and nobody is > actively monitoring new bugs in the bug tracker. The risk is to break > something and never hear about it from the users. > > > Also have some thoughts about protocol enhancements, but with mac80211 it > > is unable to stay clear about API structure to maintain and develop > > them. I'm suggesting do 80211-independent work with such enhancements, > > so it will be possible to port to mac80211, net80211 and other softmac > > realizations, but for primer work - use madwifi. > > I used MadWifi to experiment with using kernel CCM encryption. MadWifi > was more convenient because it has a testsuite for CCMP. > > But generally, I think we should try to make mac80211 suitable for > everything, including prototyping of new protocols. It is sad to know that you are the one who don't let madwifi be abandoned. With all this situation around madwifi I'll try to fix prior bugs in madwifi, maybe port 802.11n and then maybe stop developing it, if i'll get same functionality with mac80211+atheros drivers in mainline kernel. Regards. |
From: Felix F. <nb...@op...> - 2010-03-27 23:54:06
|
On 2010-03-27 12:26 AM, N.Leiten wrote: > It is sad to know that you are the one who don't let madwifi be abandoned. > With all this situation around madwifi I'll try to fix prior bugs in madwifi, > maybe port 802.11n and then maybe stop developing it, if i'll get same > functionality with mac80211+atheros drivers in mainline kernel. Why would anybody want to port 802.11n to madwifi? ath9k/mac80211 already provides much more functionality and stability than madwifi could ever hope to achieve. - Felix |
From: N.Leiten <nic...@gm...> - 2010-03-30 09:10:19
|
В сообщении от Воскресенье 28 марта 2010 01:18:12 автор Felix Fietkau написал: > On 2010-03-27 12:26 AM, N.Leiten wrote: > > It is sad to know that you are the one who don't let madwifi be > > abandoned. With all this situation around madwifi I'll try to fix prior > > bugs in madwifi, maybe port 802.11n and then maybe stop developing it, > > if i'll get same functionality with mac80211+atheros drivers in mainline > > kernel. > > Why would anybody want to port 802.11n to madwifi? ath9k/mac80211 > already provides much more functionality and stability than madwifi > could ever hope to achieve. > > - Felix Two years ago I tried to work with ath5k and mac80211, but it was either unstable or buggy in some cases. Indeed, now it has stabilized and get more functionality, so in time I'll try to port own projects to mac80211, but for exact this moment it'll get less time to fix madwifi and port new hardware support from BSD code to madwifi. Also, codebase in madwifi are well documented and has its architecture to implement special protocols or test some functionality. Regards. |