Thread: [Madwifi-devel] [ANNOUNCE] MadWifi project moves away from binary-only HAL in favor of ath5k
Status: Beta
Brought to you by:
otaku
From: Michael R. <mre...@ma...> - 2007-09-20 14:58:35
|
Hi all. We, the MadWifi team, announce our decision to move away from the binary-only HAL and change the focus of our future development towards ath5k [1], a completely free (as in freedom) driver which will eventually become an integral part of the Linux kernel. We encourage all interested developers to join us and contribute to our efforts. For those who are not familiar with the concept, the proprietary "Hardware Abstraction Layer" (HAL) [2] was designed as compromise to allow at least one Free and Open Source Software (FOSS) wireless driver component. Unlike many other wireless devices Atheros chipsets can use a wide range of frequencies and the host software can control many aspects of the radio. Regulatory agencies all over the world have laws which restrict the use of the wireless spectrum to certain frequency bands under specific transmission power levels. These laws drive wireless manufacturers to come up with solutions to enforce compliance with the wide array of regulatory agencies. The binary HAL is a wrapper around all chipset registers, and all direct hardware access is routed through it. This approach ensures that non-compliant settings are not applied to the radio, while allowing the open source part of the driver to interact with the chipset in a permissive manner. We understand Atheros' reasons for introducing the HAL and distributing it in binary form only, and we supported it. But this decision forced us to deal with a black box that we could neither fix nor fully understand - a major issue for a free software project. This prevented MadWifi from appearing in many Linux distributions. Because of the proprietary HAL and since the MadWifi driver also did not make use of the new mac80211 layer in Linux it has been impossible for it to become part of the Linux kernel. It's also been clear to us that the "security through obscurity" approach won't work to protect the hardware against unlawful use. Regardless, we kept working on MadWifi as no acceptable alternative existed. This situation has changed. A driver for Atheros wireless cards is available in OpenBSD that talks directly to the hardware, based on reverse engineering efforts done by Reyk Floeter. Relevant parts of the driver have been ported to Linux by Nick Kossifidis to start OpenHAL [3], a free (as in freedom) replacement of the proprietary HAL. Claims that the OpenBSD driver (and thus also OpenHAL) contains stolen code slowed down the OpenHAL efforts but finally could be voided. The Software Freedom Law Center (SFLC) [4], with the help of Atheros, performed a thorough code review and concluded "that OpenHAL does not infringe copyrights held by Atheros" [5]. In other words, the way is clear now for the inclusion of an OpenHAL-based driver into the Linux kernel. Another important development is the work on a "central regulatory domain agent". It aims to ensure compliance with the regulatory constraints and rules based on the current location of the user. The agent and its integration with the kernel will allow wireless LAN drivers to enforce local regulations without requiring non-free software for that task. This work will soon be published for merging with the upstream kernel. We now see a road to move away from the binary-only HAL; it's no comfortable road, however, and thus requires full concentration of our resources to finally reach the ultimate goal of getting a free driver for Atheros devices into the Linux kernel. This free driver is called ath5k, and the work on it has already been started. We are also in contact with Atheros to encourage them to support these efforts. To underline our decision and commitment to ath5k we now declare MadWifi "legacy.". In the long run ath5k will replace the MadWifi driver. For the time being MadWifi will still be supported, bugs will get fixed and HAL updates will be applied where possible. But it becomes unlikely that we'll see new features or go through major changes on that codebase. The only exception to this is the work spent on improved support for Dynamic Frequency Selection (DFS) [6], which is used for avoiding interference with radars. Users who need stable and solid WLAN support for their Linux computers should stick with MadWifi for now. Interested parties are welcome to try ath5k and any constructive feedback is highly appreciated. We encourage developers to contribute [7] to the free driver efforts - it's still a long way before we reach the goal of a truly free Atheros driver for Linux, and every helping hand is welcome. If you have any questions, feel free to ask. Thanks for listening. -- The MadWifi Team Links: [1] http://madwifi.org/wiki/About/ath5k [2] http://madwifi.org/wiki/About/HAL [3] http://madwifi.org/wiki/About/OpenHAL [4] http://softwarefreedom.org/ [5] http://www.softwarefreedom.org/news/2007/jul/31/openhal/ [6] http://en.wikipedia.org/wiki/IEEE_802.11h#DFS_Dynamic_Frequency_Selection [7] http://linuxwireless.org/en/users/Drivers/ath5k#Hackingath5k |
From: Holger S. <hs...@ma...> - 2007-09-21 07:14:43
|
> We, the MadWifi team, announce our decision to move away from > the binary-only HAL and change the focus of our future > development towards ath5k [1] Congratulations ! I also thought about going to bcm43xx based WLAN cards, as they are now working much better than two months ago ... and, from a what-happens-in-linux-kernel-perspective, it seamed much more lively and healthy. For example, several people tried to get better roaming support into madwifi. That's basically a job for net80211, not for the atheros chipset. But the madwifi project lacked people with enought time and knowledge in the net80211 area, so no peer review did happen and, of course, the code in the madwifi svn didn't get changed, so madwifi still doesn't roam more smoothly. So, by moving to ath5k, which is using mac80211, there is no need to have people that know and can maintain BSD's net80211 inside Linux. We get the best from both worlds: some very knowledgeable people in the mac80211 area, and some very knowledgeable persons in the atheros driver area. I like that :-) |
From: Michael M. <133...@gm...> - 2007-09-24 20:38:12
|
This sounds great! Moving to OpenHAL should benefit madwifi in many ways. There is only one thing I question: "Another important development is the work on a "central regulatory domain agent". It aims to ensure compliance with the regulatory constraints and rules based on the current location of the user. The agent and its integration with the kernel will allow wireless LAN drivers to enforce local regulations without requiring non-free software for that task. This work will soon be published for merging with the upstream kernel." In my opinion, protection should not be in the software for such things. While Atheros may be required by law to do this, madwifi (this is NOT legal advice in any way shape or form) is not required to do so. One comparison which can be made to this situation is that of VLC. Whereas commercial DVD playing apps look at region codes, VLC ignores them. VLC could choose to abide by these codes and put code in to stop the wrong region from playing, but the project chooses not to. Madwifi should do the same. Another comparison is the GPL kernel module debate. The kernel was made to prohibit access to certain symbols for programs which were not GPLd by checking the Module_License to see if it was equal to GPL. Linuxant got around this by setting the Module_License to "GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies." The null character made this effectively "GPL" so the kernel loaded the proprietary modules as if they were GPL. Now, Linus Torvalds got a bunch of patches to fix this. However, his response was this: "I'd prefer not to do that. Since they want to circumvent this, almost anything we want to do is a waste of time." He too offered a patch, adding to it the byline, "Arms race forces bloat upon module users" [1]. This is the philosophy that madwifi needs to abide by. Don't protect your code from hackers, or people wanting to abuse it. Developers should just focus on making the best Linux Atheros driver possible, and not worry themselves with providing protection against purposefully misusing the software. -- Mike [1] http://kerneltrap.org/node/2991 On 9/20/07, Michael Renzmann <mre...@ma...> wrote: > Hi all. > > We, the MadWifi team, announce our decision to move away from the > binary-only HAL and change the focus of our future development towards > ath5k [1], a completely free (as in freedom) driver which will eventually > become an integral part of the Linux kernel. We encourage all interested > developers to join us and contribute to our efforts. > > For those who are not familiar with the concept, the proprietary "Hardware > Abstraction Layer" (HAL) [2] was designed as compromise to allow at least > one Free and Open Source Software (FOSS) wireless driver component. Unlike > many other wireless devices Atheros chipsets can use a wide range of > frequencies and the host software can control many aspects of the radio. > Regulatory agencies all over the world have laws which restrict the use of > the wireless spectrum to certain frequency bands under specific > transmission power levels. These laws drive wireless manufacturers to come > up with solutions to enforce compliance with the wide array of regulatory > agencies. The binary HAL is a wrapper around all chipset registers, and > all direct hardware access is routed through it. This approach ensures > that non-compliant settings are not applied to the radio, while allowing > the open source part of the driver to interact with the chipset in a > permissive manner. > > We understand Atheros' reasons for introducing the HAL and distributing it > in binary form only, and we supported it. But this decision forced us to > deal with a black box that we could neither fix nor fully understand - a > major issue for a free software project. This prevented MadWifi from > appearing in many Linux distributions. Because of the proprietary HAL and > since the MadWifi driver also did not make use of the new mac80211 layer > in Linux it has been impossible for it to become part of the Linux kernel. > It's also been clear to us that the "security through obscurity" approach > won't work to protect the hardware against unlawful use. Regardless, we > kept working on MadWifi as no acceptable alternative existed. > > This situation has changed. > > A driver for Atheros wireless cards is available in OpenBSD that talks > directly to the hardware, based on reverse engineering efforts done by > Reyk Floeter. Relevant parts of the driver have been ported to Linux by > Nick Kossifidis to start OpenHAL [3], a free (as in freedom) replacement > of the proprietary HAL. Claims that the OpenBSD driver (and thus also > OpenHAL) contains stolen code slowed down the OpenHAL efforts but finally > could be voided. The Software Freedom Law Center (SFLC) [4], with the help > of Atheros, performed a thorough code review and concluded "that OpenHAL > does not infringe copyrights held by Atheros" [5]. In other words, the way > is clear now for the inclusion of an OpenHAL-based driver into the Linux > kernel. > > Another important development is the work on a "central regulatory domain > agent". It aims to ensure compliance with the regulatory constraints and > rules based on the current location of the user. The agent and its > integration with the kernel will allow wireless LAN drivers to enforce > local regulations without requiring non-free software for that task. This > work will soon be published for merging with the upstream kernel. > > We now see a road to move away from the binary-only HAL; it's no > comfortable road, however, and thus requires full concentration of our > resources to finally reach the ultimate goal of getting a free driver for > Atheros devices into the Linux kernel. This free driver is called ath5k, > and the work on it has already been started. We are also in contact with > Atheros to encourage them to support these efforts. > > To underline our decision and commitment to ath5k we now declare MadWifi > "legacy.". In the long run ath5k will replace the MadWifi driver. For the > time being MadWifi will still be supported, bugs will get fixed and HAL > updates will be applied where possible. But it becomes unlikely that we'll > see new features or go through major changes on that codebase. The only > exception to this is the work spent on improved support for Dynamic > Frequency Selection (DFS) [6], which is used for avoiding interference > with radars. > > Users who need stable and solid WLAN support for their Linux computers > should stick with MadWifi for now. Interested parties are welcome to try > ath5k and any constructive feedback is highly appreciated. > > We encourage developers to contribute [7] to the free driver efforts - > it's still a long way before we reach the goal of a truly free Atheros > driver for Linux, and every helping hand is welcome. > > If you have any questions, feel free to ask. Thanks for listening. > > -- The MadWifi Team > > Links: > [1] http://madwifi.org/wiki/About/ath5k > [2] http://madwifi.org/wiki/About/HAL > [3] http://madwifi.org/wiki/About/OpenHAL > [4] http://softwarefreedom.org/ > [5] http://www.softwarefreedom.org/news/2007/jul/31/openhal/ > [6] http://en.wikipedia.org/wiki/IEEE_802.11h#DFS_Dynamic_Frequency_Selection > [7] http://linuxwireless.org/en/users/Drivers/ath5k#Hackingath5k > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: hiwu.tw <hi...@ms...> - 2007-09-25 11:00:06
|
Hi MadWifi Team: Will there be Madwifi version 1.0 released when AR5k project is kick-off ? Thank you -Jack ----- Original Message ----- From: "Michael Miller" <133...@gm...> To: <mad...@li...>; <mad...@li...> Sent: Tuesday, September 25, 2007 4:38 AM Subject: Re: [Madwifi-devel] [ANNOUNCE] MadWifi project moves away frombinary-only HAL in favor of ath5k > This sounds great! Moving to OpenHAL should benefit madwifi in many ways. > > There is only one thing I question: "Another important development is > the work on a "central regulatory domain > agent". It aims to ensure compliance with the regulatory constraints and > rules based on the current location of the user. The agent and its > integration with the kernel will allow wireless LAN drivers to enforce > local regulations without requiring non-free software for that task. This > work will soon be published for merging with the upstream kernel." > > In my opinion, protection should not be in the software for such > things. While Atheros may be required by law to do this, madwifi (this > is NOT legal advice in any way shape or form) is not required to do > so. > > One comparison which can be made to this situation is that of VLC. > Whereas commercial DVD playing apps look at region codes, VLC ignores > them. VLC could choose to abide by these codes and put code in to stop > the wrong region from playing, but the project chooses not to. Madwifi > should do the same. > > Another comparison is the GPL kernel module debate. The kernel was > made to prohibit access to certain symbols for programs which were not > GPLd by checking the Module_License to see if it was equal to GPL. > Linuxant got around this by setting the Module_License to "GPL\0for > files in the \"GPL\" directory; for others, only LICENSE file > applies." The null character made this effectively "GPL" so the kernel > loaded the proprietary modules as if they were GPL. Now, Linus > Torvalds got a bunch of patches to fix this. However, his response was > this: "I'd prefer not to do that. Since they want to circumvent this, > almost anything we want to do is a waste of time." He too offered a > patch, adding to it the byline, "Arms race forces bloat upon module > users" [1]. This is the philosophy that madwifi needs to abide by. > Don't protect your code from hackers, or people wanting to abuse it. > Developers should just focus on making the best Linux Atheros driver > possible, and not worry themselves with providing protection against > purposefully misusing the software. > > -- Mike > > [1] http://kerneltrap.org/node/2991 > > On 9/20/07, Michael Renzmann <mre...@ma...> wrote: >> Hi all. >> >> We, the MadWifi team, announce our decision to move away from the >> binary-only HAL and change the focus of our future development towards >> ath5k [1], a completely free (as in freedom) driver which will eventually >> become an integral part of the Linux kernel. We encourage all interested >> developers to join us and contribute to our efforts. >> >> For those who are not familiar with the concept, the proprietary >> "Hardware >> Abstraction Layer" (HAL) [2] was designed as compromise to allow at least >> one Free and Open Source Software (FOSS) wireless driver component. >> Unlike >> many other wireless devices Atheros chipsets can use a wide range of >> frequencies and the host software can control many aspects of the radio. >> Regulatory agencies all over the world have laws which restrict the use >> of >> the wireless spectrum to certain frequency bands under specific >> transmission power levels. These laws drive wireless manufacturers to >> come >> up with solutions to enforce compliance with the wide array of regulatory >> agencies. The binary HAL is a wrapper around all chipset registers, and >> all direct hardware access is routed through it. This approach ensures >> that non-compliant settings are not applied to the radio, while allowing >> the open source part of the driver to interact with the chipset in a >> permissive manner. >> >> We understand Atheros' reasons for introducing the HAL and distributing >> it >> in binary form only, and we supported it. But this decision forced us to >> deal with a black box that we could neither fix nor fully understand - a >> major issue for a free software project. This prevented MadWifi from >> appearing in many Linux distributions. Because of the proprietary HAL and >> since the MadWifi driver also did not make use of the new mac80211 layer >> in Linux it has been impossible for it to become part of the Linux >> kernel. >> It's also been clear to us that the "security through obscurity" approach >> won't work to protect the hardware against unlawful use. Regardless, we >> kept working on MadWifi as no acceptable alternative existed. >> >> This situation has changed. >> >> A driver for Atheros wireless cards is available in OpenBSD that talks >> directly to the hardware, based on reverse engineering efforts done by >> Reyk Floeter. Relevant parts of the driver have been ported to Linux by >> Nick Kossifidis to start OpenHAL [3], a free (as in freedom) replacement >> of the proprietary HAL. Claims that the OpenBSD driver (and thus also >> OpenHAL) contains stolen code slowed down the OpenHAL efforts but finally >> could be voided. The Software Freedom Law Center (SFLC) [4], with the >> help >> of Atheros, performed a thorough code review and concluded "that OpenHAL >> does not infringe copyrights held by Atheros" [5]. In other words, the >> way >> is clear now for the inclusion of an OpenHAL-based driver into the Linux >> kernel. >> >> Another important development is the work on a "central regulatory domain >> agent". It aims to ensure compliance with the regulatory constraints and >> rules based on the current location of the user. The agent and its >> integration with the kernel will allow wireless LAN drivers to enforce >> local regulations without requiring non-free software for that task. This >> work will soon be published for merging with the upstream kernel. >> >> We now see a road to move away from the binary-only HAL; it's no >> comfortable road, however, and thus requires full concentration of our >> resources to finally reach the ultimate goal of getting a free driver for >> Atheros devices into the Linux kernel. This free driver is called ath5k, >> and the work on it has already been started. We are also in contact with >> Atheros to encourage them to support these efforts. >> >> To underline our decision and commitment to ath5k we now declare MadWifi >> "legacy.". In the long run ath5k will replace the MadWifi driver. For the >> time being MadWifi will still be supported, bugs will get fixed and HAL >> updates will be applied where possible. But it becomes unlikely that >> we'll >> see new features or go through major changes on that codebase. The only >> exception to this is the work spent on improved support for Dynamic >> Frequency Selection (DFS) [6], which is used for avoiding interference >> with radars. >> >> Users who need stable and solid WLAN support for their Linux computers >> should stick with MadWifi for now. Interested parties are welcome to try >> ath5k and any constructive feedback is highly appreciated. >> >> We encourage developers to contribute [7] to the free driver efforts - >> it's still a long way before we reach the goal of a truly free Atheros >> driver for Linux, and every helping hand is welcome. >> >> If you have any questions, feel free to ask. Thanks for listening. >> >> -- The MadWifi Team >> >> Links: >> [1] http://madwifi.org/wiki/About/ath5k >> [2] http://madwifi.org/wiki/About/HAL >> [3] http://madwifi.org/wiki/About/OpenHAL >> [4] http://softwarefreedom.org/ >> [5] http://www.softwarefreedom.org/news/2007/jul/31/openhal/ >> [6] >> http://en.wikipedia.org/wiki/IEEE_802.11h#DFS_Dynamic_Frequency_Selection >> [7] http://linuxwireless.org/en/users/Drivers/ath5k#Hackingath5k >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Madwifi-devel mailing list >> Mad...@li... >> https://lists.sourceforge.net/lists/listinfo/madwifi-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel |
From: Michael R. <mre...@ma...> - 2007-09-26 04:12:13
|
Hi. CC to madwifi-users removed. > Will there be Madwifi version 1.0 released when AR5k project is kick-off ? ar5k is the OpenBSD driver, so I guess you mean ath5k here. Given that a new release - especially one that carries the version number from 0.x to 1.x - is expected to contain new functionality it seems unlikely (but not absolutely impossible) that we will release v1.0 of MadWifi. The core team wants to concentrate on ath5k, which is why we declared MadWifi legacy. Bye, Mike |
From: Pavel R. <pr...@gn...> - 2007-09-25 22:30:03
|
Hello! On Mon, 2007-09-24 at 16:38 -0400, Michael Miller wrote: > In my opinion, protection should not be in the software for such > things. While Atheros may be required by law to do this, madwifi (this > is NOT legal advice in any way shape or form) is not required to do > so. It's a separate effort from MadWifi, not limited to specific wireless drivers. > One comparison which can be made to this situation is that of VLC. > Whereas commercial DVD playing apps look at region codes, VLC ignores > them. VLC could choose to abide by these codes and put code in to stop > the wrong region from playing, but the project chooses not to. Madwifi > should do the same. The difference here is that wireless developers actually expect to work with the device vendors. The vendors may be more forthcoming if the free driver supports regulatory control (directly or through some other layers). Anyway, the regulatory control patches are discussed in lin...@vg..., not here. Please don't cross-post unless you are a member of the team and you are making an announcement. You are giving a bad example to others. -- Regards, Pavel Roskin |
From: Michael M. <133...@gm...> - 2007-09-25 22:51:20
|
On 9/25/07, Pavel Roskin <pr...@gn...> wrote: > Hello! > > On Mon, 2007-09-24 at 16:38 -0400, Michael Miller wrote: > > > In my opinion, protection should not be in the software for such > > things. While Atheros may be required by law to do this, madwifi (this > > is NOT legal advice in any way shape or form) is not required to do > > so. > > It's a separate effort from MadWifi, not limited to specific wireless > drivers. > So it's going in the net80211 stack? Hrm... maybe I should post my opinions on their mailing list.... > > One comparison which can be made to this situation is that of VLC. > > Whereas commercial DVD playing apps look at region codes, VLC ignores > > them. VLC could choose to abide by these codes and put code in to stop > > the wrong region from playing, but the project chooses not to. Madwifi > > should do the same. > > The difference here is that wireless developers actually expect to work > with the device vendors. The vendors may be more forthcoming if the > free driver supports regulatory control (directly or through some other > layers). Here's where I'm confused. Madwifi is going AWAY from Atheros' assistance(moving away from the HAL). Moreover, why should Atheros(or any other company for that matter) care if other people choose to transmit over other frequencies? (The following is not legal advice, do not use it as such) Atheros does not get blamed if other people use their own software to interfere with wireless signals. > Anyway, the regulatory control patches are discussed in > lin...@vg..., not here. > > Please don't cross-post unless you are a member of the team and you are > making an announcement. You are giving a bad example to others. My apologies, Mike > > -- > Regards, > Pavel Roskin > > |
From: Michael R. <mre...@ma...> - 2007-09-26 04:23:52
|
Hi. >> It's a separate effort from MadWifi, not limited to specific wireless >> drivers. > So it's going in the net80211 stack? Hrm... maybe I should post my > opinions on their mailing list.... The relevant discussions can be found here: http://thread.gmane.org/gmane.linux.kernel.wireless.general/6049 http://thread.gmane.org/gmane.linux.kernel.wireless.general/6073 > Here's where I'm confused. Madwifi is going AWAY from Atheros' > assistance (moving away from the HAL). Wrong. While we move away from the proprietary HAL, we don't move away from Atheros. As stated in the announcement we're in contact with Atheros to win their support for ath5k and the CRDA-related work. > Moreover, why should Atheros (or any other company for that matter) care > if other people choose to transmit over other frequencies? >From what I understood of past discussions (that I've followed loosely, so I could be wrong here): Because of the FCC rules that seem to require device vendors (that's not Atheros, but Atheros customers such as D-Link, Netgear and others) to make sure that their products can't be "abused" to easily break the regulatory rules, otherwise these products won't get FCC certification and thus are not allowed to be sold in FCC-regulated countries. Other regulatory bodies have similar rules, afaik. Bye, Mike |
From: David M. <301...@st...> - 2007-09-27 17:03:39
|
Hi, The current open HAL looks similar to madwifi-old which I really liked but some of the features like background scanning are absent. I am interested to know how much of the code that was developed for the madwifi driver with the proprietary HAL will be reusable in the new OpenHAL version? Will the aim be to get the driver back to the same state or will there be large modifications with the added flexibility of an open source HAL. I hope this does not come across as critical because it is not intended to be. Cheers Dave Quoting Michael Miller <133...@gm...>: > This sounds great! Moving to OpenHAL should benefit madwifi in many ways. > > There is only one thing I question: "Another important development is > the work on a "central regulatory domain > agent". It aims to ensure compliance with the regulatory constraints and > rules based on the current location of the user. The agent and its > integration with the kernel will allow wireless LAN drivers to enforce > local regulations without requiring non-free software for that task. This > work will soon be published for merging with the upstream kernel." > > In my opinion, protection should not be in the software for such > things. While Atheros may be required by law to do this, madwifi (this > is NOT legal advice in any way shape or form) is not required to do > so. > > One comparison which can be made to this situation is that of VLC. > Whereas commercial DVD playing apps look at region codes, VLC ignores > them. VLC could choose to abide by these codes and put code in to stop > the wrong region from playing, but the project chooses not to. Madwifi > should do the same. > > Another comparison is the GPL kernel module debate. The kernel was > made to prohibit access to certain symbols for programs which were not > GPLd by checking the Module_License to see if it was equal to GPL. > Linuxant got around this by setting the Module_License to "GPL\0for > files in the \"GPL\" directory; for others, only LICENSE file > applies." The null character made this effectively "GPL" so the kernel > loaded the proprietary modules as if they were GPL. Now, Linus > Torvalds got a bunch of patches to fix this. However, his response was > this: "I'd prefer not to do that. Since they want to circumvent this, > almost anything we want to do is a waste of time." He too offered a > patch, adding to it the byline, "Arms race forces bloat upon module > users" [1]. This is the philosophy that madwifi needs to abide by. > Don't protect your code from hackers, or people wanting to abuse it. > Developers should just focus on making the best Linux Atheros driver > possible, and not worry themselves with providing protection against > purposefully misusing the software. > > -- Mike > > [1] http://kerneltrap.org/node/2991 > > On 9/20/07, Michael Renzmann <mre...@ma...> wrote: >> Hi all. >> >> We, the MadWifi team, announce our decision to move away from the >> binary-only HAL and change the focus of our future development towards >> ath5k [1], a completely free (as in freedom) driver which will eventually >> become an integral part of the Linux kernel. We encourage all interested >> developers to join us and contribute to our efforts. >> >> For those who are not familiar with the concept, the proprietary "Hardware >> Abstraction Layer" (HAL) [2] was designed as compromise to allow at least >> one Free and Open Source Software (FOSS) wireless driver component. Unlike >> many other wireless devices Atheros chipsets can use a wide range of >> frequencies and the host software can control many aspects of the radio. >> Regulatory agencies all over the world have laws which restrict the use of >> the wireless spectrum to certain frequency bands under specific >> transmission power levels. These laws drive wireless manufacturers to come >> up with solutions to enforce compliance with the wide array of regulatory >> agencies. The binary HAL is a wrapper around all chipset registers, and >> all direct hardware access is routed through it. This approach ensures >> that non-compliant settings are not applied to the radio, while allowing >> the open source part of the driver to interact with the chipset in a >> permissive manner. >> >> We understand Atheros' reasons for introducing the HAL and distributing it >> in binary form only, and we supported it. But this decision forced us to >> deal with a black box that we could neither fix nor fully understand - a >> major issue for a free software project. This prevented MadWifi from >> appearing in many Linux distributions. Because of the proprietary HAL and >> since the MadWifi driver also did not make use of the new mac80211 layer >> in Linux it has been impossible for it to become part of the Linux kernel. >> It's also been clear to us that the "security through obscurity" approach >> won't work to protect the hardware against unlawful use. Regardless, we >> kept working on MadWifi as no acceptable alternative existed. >> >> This situation has changed. >> >> A driver for Atheros wireless cards is available in OpenBSD that talks >> directly to the hardware, based on reverse engineering efforts done by >> Reyk Floeter. Relevant parts of the driver have been ported to Linux by >> Nick Kossifidis to start OpenHAL [3], a free (as in freedom) replacement >> of the proprietary HAL. Claims that the OpenBSD driver (and thus also >> OpenHAL) contains stolen code slowed down the OpenHAL efforts but finally >> could be voided. The Software Freedom Law Center (SFLC) [4], with the help >> of Atheros, performed a thorough code review and concluded "that OpenHAL >> does not infringe copyrights held by Atheros" [5]. In other words, the way >> is clear now for the inclusion of an OpenHAL-based driver into the Linux >> kernel. >> >> Another important development is the work on a "central regulatory domain >> agent". It aims to ensure compliance with the regulatory constraints and >> rules based on the current location of the user. The agent and its >> integration with the kernel will allow wireless LAN drivers to enforce >> local regulations without requiring non-free software for that task. This >> work will soon be published for merging with the upstream kernel. >> >> We now see a road to move away from the binary-only HAL; it's no >> comfortable road, however, and thus requires full concentration of our >> resources to finally reach the ultimate goal of getting a free driver for >> Atheros devices into the Linux kernel. This free driver is called ath5k, >> and the work on it has already been started. We are also in contact with >> Atheros to encourage them to support these efforts. >> >> To underline our decision and commitment to ath5k we now declare MadWifi >> "legacy.". In the long run ath5k will replace the MadWifi driver. For the >> time being MadWifi will still be supported, bugs will get fixed and HAL >> updates will be applied where possible. But it becomes unlikely that we'll >> see new features or go through major changes on that codebase. The only >> exception to this is the work spent on improved support for Dynamic >> Frequency Selection (DFS) [6], which is used for avoiding interference >> with radars. >> >> Users who need stable and solid WLAN support for their Linux computers >> should stick with MadWifi for now. Interested parties are welcome to try >> ath5k and any constructive feedback is highly appreciated. >> >> We encourage developers to contribute [7] to the free driver efforts - >> it's still a long way before we reach the goal of a truly free Atheros >> driver for Linux, and every helping hand is welcome. >> >> If you have any questions, feel free to ask. Thanks for listening. >> >> -- The MadWifi Team >> >> Links: >> [1] http://madwifi.org/wiki/About/ath5k >> [2] http://madwifi.org/wiki/About/HAL >> [3] http://madwifi.org/wiki/About/OpenHAL >> [4] http://softwarefreedom.org/ >> [5] http://www.softwarefreedom.org/news/2007/jul/31/openhal/ >> [6] >> http://en.wikipedia.org/wiki/IEEE_802.11h#DFS_Dynamic_Frequency_Selection >> [7] http://linuxwireless.org/en/users/Drivers/ath5k#Hackingath5k >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Madwifi-devel mailing list >> Mad...@li... >> https://lists.sourceforge.net/lists/listinfo/madwifi-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: Luis R. R. <mc...@gm...> - 2007-09-27 18:20:42
|
On 9/27/07, David Murray <301...@st...> wrote: > Hi, > > The current open HAL looks similar to madwifi-old which I really liked > but some of the features like background scanning are absent. I am > interested to know how much of the code that was developed for the > madwifi driver with the proprietary HAL will be reusable in the new > OpenHAL version? Any old legacy madwifi driver (which uses the proprietary HAL) relies on net80211, with the exception of dadwifi-openahal. dadwifi-openhal is now replaced though with ath5k [1]. ath5k uses the new Linux mac80211[1]. Since net80211 is 'complete wireless stack' and mac80211 is a 'Linux API used to write SoftMAC wireless drivers' the drivers as a whole differ significantly. As such only small portions of the driver were reusable, and those that were made it into ath5k_base.[ch]. > Will the aim be to get the driver back to the same > state or will there be large modifications with the added flexibility > of an open source HAL. I hope this does not come across as critical > because it is not intended to be. New development is going to be focused on ath5k. Relying on the proprietary HAL has been like working with a black box and the legacy drivers also rely on Wireless-Extensions which will not longer have new features added, preventing us from extending the usage and features of the driver. To reap benefits of the latest Linux wireless developments we must focus on mac80211, cfg80211 [3] and nl80211 [4]. cfg80211 and nl80211 is still under development and we are yet to provide userspace utilities for them. However, mac80211 is now part of the stock kernel and as such we are working on stabilizing it. In the meantime I'd advise users to look in to wpa_supplicant [5] and hostapd [6]. You can also still use wireless-tools (iwconfig, iwlist, iwevent) with ath5k and any mac80211 driver. Luis [1] http://madwifi.org/wiki/About/ath5k [2] http://linuxwireless.org/en/developers/mac80211 [3] http://linuxwireless.org/en/developers/cfg80211 [4] http://linuxwireless.org/en/developers/nl80211 [5] http://hostap.epitest.fi/wpa_supplicant/ [6] http://hostap.epitest.fi/hostapd/ |
From: hiwu.tw <hi...@ms...> - 2007-10-08 11:49:47
|
Hi all: In ath_rx_tasklet(), sometime HAL will set "rs_ststus = 1" Why HAL set the rs_status "1" (HAL_ENXIO, No hardware present) ? What does "No hardware present" mean? Thank you -Jack |
From: Matthew 'm. B. <me...@ma...> - 2007-10-08 12:55:01
|
Hi Jack, Would you please stop posting new threads as responses to other, unreleated threads? It's a little bit annoying. Matthew On Mon, 2007-10-08 at 19:49 +0800, hiwu.tw wrote: <snip> |