Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Just in case you want to experiment, i have a working port of ar5k
that works on madwifi-old before the BSD - HEAD merge...
well i'm no good programmer (yet), i did what i could (i'm sure those
define macros are nasty for most people :P) and hope that helps...
you can git clone from the following link
rsync://rsync.ath-driver.org/gnumonks_users/mb/openhal.git
I'm working with the following madwifi revision...
svn checkout http://svn.madwifi.org/branches/madwifi-old -r 1142 madwifi
Don't forget to remove the ending ) in line 175 at
net80211/ieee80211_radiotap.h ;-)
Also you'll need to do some modifications to make it work with newer
kernel versions (MODULE_PARM stuff in if_ath.c)...
diff -Naurp madwifi-openhal/ath/if_ath.c madwifi-openhal-fixed/ath/if_ath.c
--- madwifi-openhal/ath/if_ath.c2005-06-24 06:41:22.0 -0400
+++ madwifi-openhal-fixed/ath/if_ath.c 2006-08-04 14:49:38.0 -0400
@@ -245,13 +245,20 @@ enum {
#endif
static int countrycode = -1;
-MODULE_PARM(countrycode, i);
-MODULE_PARM_DESC(countrycode, Override default country code);
static int outdoor = -1;
-MODULE_PARM(outdoor, i);
-MODULE_PARM_DESC(outdoor, Enable/disable outdoor use);
static int xchanmode = -1;
+#if (LINUX_VERSION_CODE KERNEL_VERSION(2,5,52))
+MODULE_PARM(countrycode, i);
+MODULE_PARM(outdoor, i);
MODULE_PARM(xchanmode, i);
+#else
+#include linux/moduleparam.h
+module_param(countrycode, int, 0);
+module_param(outdoor, int, 0);
+module_param(xchanmode, int, 0);
+#endif
+MODULE_PARM_DESC(countrycode, Override default country code);
+MODULE_PARM_DESC(outdoor, Enable/disable outdoor use);
MODULE_PARM_DESC(xchanmode, Enable/disable extended channel mode);
int
See README for more details
I haven't looked much the MadWiFi code since then, perhaps you can
help in making ar5k work with newer madwifi versions + improve it's
functionality to help both linux and OpenBSD.
(The name OpenHAL came from John Bicket's initial port)
Happy coding ;-)
Nick
2006/11/16, Michael Renzmann [EMAIL PROTECTED]:
Hi.
Michael Buesch wrote:
Well, it never worked for me. But I gave up trying about
half a year ago. But maybe it's just stupid me. ;)
Well, we have various support channels (an IRC channel besides two
mailing lists, for example) that you are welcome to make use of in case
of problems :)
Bye, Mike
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Madwifi-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wed, 2006-11-15 at 14:39 -0500, Pavel Roskin wrote: Hello! On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. I said it before, and it's worth repeating. Dissolving HAL in the sources is easy. It's just a matter of moving functions around without serious chances of breaking anything as long as the source compiles. The whole HAL-based architecture can be reshuffled and eliminated by one person in a few days. Making things work properly takes years. That's what MadWifi has been working on for a long time, using contributions and bug reports from scores of users and developers. Rejecting MadWifi because it's HAL based is like throwing away a diamond ring because it's too narrow. No, I'd personally reject madwifi not because of the HAL but because it uses the net80211 stack [1]. We don't need another 802.11 stack in the Linux kernel, of course. But since the Devicescape people have already ported madwifi to d80211 (see David Kimdon's announcement on netdev on Oct. 17th), that appears to be a valid path to follow and at least some of the work has already been done. If the HAL bits were ported to ar5k and folded back into the driver, I think that would be a great start. Dan [1] nothing against net80211; it's a fine stack. But There Can Be Only One, if just for sanity's sake. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. At least, this way we have a chance to get USB working as well (See http://madwifi.org/ticket/33). It's not the HAL that prevents MadWifi implementing USB support. Replacing the binary-only HAL with OpenHAL and/or dissolving the HAL functionality in the driver source does not get us any closer to a working support of USB sticks. Quoting Sam Leffler on that topic: === cut === The Atheros-based USB devices work rather differently from the cardbus/pci cards. In particular there is no hal; instead there's an onboard processor that runs the hal and implements a special protocol. This means you can reuse some of madwifi but you also (probably) need to redo the code some to break out different interfaces. It's not a simple project. === cut === see: http://article.gmane.org/gmane.linux.drivers.madwifi.user/5380 OpenBSD seems to have a working driver (if_uath.c) for these USB WLAN sticks. Which, at least for some sticks, requires a not freely distributable binary firmware blob, by the way (see: http://archives.neohapsis.com/archives/openbsd/cvs/2006-09/0233.html ). Nevertheless, it would be nice to have that driver ported to Linux. Bye, Mike - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wednesday 15 November 2006 04:10, John W. Linville wrote: It is my pleasure to announce that the SFLC [1] has assisted the ar5k developers in evaluating the development history of Reyk Floeter's OpenBSD reverse-engineered Atheros HAL, ar5k [2]. SFLC's assessment leads to the conclusion that free software developers should not be worried about using/extending ar5k or porting ar5k to other platforms. In the past there were serious questions raised and even dire warnings made about ar5k's copyright status. The purpose of this statement is to refute those claims and to publicly clarify ar5k's status to developers. SFLC has made independent inquiries with the OpenBSD team regarding the development history of ar5k source. The responses received provide a reasonable basis for SFLC to believe that the OpenBSD developers who worked on ar5k did not misappropriate code, and that the ar5k implementation is OpenBSD's original copyrighted work. This announcement should serve to remove the cloud which has prevented progress towards an in-kernel driver for Atheros hardware. This should be of particular interest to those involved with the DadWifi project [3]. I'd like to take this opportunity to thank the folks at the SFLC for their hard work, and I'd also like to personally thank Luis Rodriguez for the role he played in coordinating contact between the SFLC and the community at large. Thanks! John [1] http://www.softwarefreedom.org/ [2] http://team.vantronix.net/ar5k/ [3] http://marc.theaimsgroup.com/?l=linux-netdevm=116113064513921w=2 So, who is finally going to _DO_ the work? Some of you know that I started an atheros driver at http://bu3sch.de/ath/atheros.git/ It's not really a driver, yet, as nobody got to continue on the specification, so I was stuck. Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. The point is that the ar5k is now safe to be used as a reference and source of information (and code, as appropriate) without copyright FUD. Distilling that information into a proper Linux driver is work that remains to be done. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Michael Buesch wrote: Yeah, ok. I'll look what I can do. First I'll have to read the code. and understand it. DMA stuff seems to be really obfuscated though dozens of callbacks, heh. :) I'd certainly like to see solid Atheros chipset support in mainline. If you need any hardware or other resources to help with this effort, let me know. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. The point is that the ar5k is now safe to be used as a reference and source of information (and code, as appropriate) without copyright FUD. Distilling that information into a proper Linux driver is work that remains to be done. there have been several efforts on this before; is it worth revitalizing one of them? Also I suspect that if you merge a provisional driver early, lots of folks will switch to it and start beating on it and fixing the style etc issues... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hello! On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. I said it before, and it's worth repeating. Dissolving HAL in the sources is easy. It's just a matter of moving functions around without serious chances of breaking anything as long as the source compiles. The whole HAL-based architecture can be reshuffled and eliminated by one person in a few days. Making things work properly takes years. That's what MadWifi has been working on for a long time, using contributions and bug reports from scores of users and developers. Rejecting MadWifi because it's HAL based is like throwing away a diamond ring because it's too narrow. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wednesday 15 November 2006 20:39, Pavel Roskin wrote: Hello! On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: Now that it seems to be ok to use these openbsd sources, should I port them to my driver framework? I looked over the ar5k code and, well, I don't like it. ;) I don't really like having a HAL. I'd rather prefer a real driver without that HAL obfuscation. I don't think anyone likes the HAL-based architecture. I don't think we will accept a HAL-based driver into the upstream kernel. I said it before, and it's worth repeating. Dissolving HAL in the sources is easy. It's just a matter of moving functions around without serious chances of breaking anything as long as the source compiles. The whole HAL-based architecture can be reshuffled and eliminated by one person in a few days. I'll look at it tomorrow. Probably best to merge this stuff into the tree somehow to get it working and clean it up afterwards. Shouldn't be too hard to merge. Making things work properly takes years. That's what MadWifi has been working on for a long time, using contributions and bug reports from scores of users and developers. Rejecting MadWifi because it's HAL based is like throwing away a diamond ring because it's too narrow. Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. Michael Buesch wrote: Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) Well, we have various support channels (an IRC channel besides two mailing lists, for example) that you are welcome to make use of in case of problems :) Bye, Mike - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
It is my pleasure to announce that the SFLC [1] has assisted the ar5k developers in evaluating the development history of Reyk Floeter's OpenBSD reverse-engineered Atheros HAL, ar5k [2]. SFLC's assessment leads to the conclusion that free software developers should not be worried about using/extending ar5k or porting ar5k to other platforms. In the past there were serious questions raised and even dire warnings made about ar5k's copyright status. The purpose of this statement is to refute those claims and to publicly clarify ar5k's status to developers. SFLC has made independent inquiries with the OpenBSD team regarding the development history of ar5k source. The responses received provide a reasonable basis for SFLC to believe that the OpenBSD developers who worked on ar5k did not misappropriate code, and that the ar5k implementation is OpenBSD's original copyrighted work. This announcement should serve to remove the cloud which has prevented progress towards an in-kernel driver for Atheros hardware. This should be of particular interest to those involved with the DadWifi project [3]. I'd like to take this opportunity to thank the folks at the SFLC for their hard work, and I'd also like to personally thank Luis Rodriguez for the role he played in coordinating contact between the SFLC and the community at large. Thanks! John [1] http://www.softwarefreedom.org/ [2] http://team.vantronix.net/ar5k/ [3] http://marc.theaimsgroup.com/?l=linux-netdevm=116113064513921w=2 -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
