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-netdev&m=116113064513921&w=2
--
John W. Linville
[email protected]
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-netdev&m=116113064513921&w=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.
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]
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
On Wednesday 15 November 2006 20:21, 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.
Yeah, wanted to hear that. ;)
> 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.
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. :)
--
Greetings Michael.
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
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
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.
On Wed, Nov 15, 2006 at 02:39:01PM -0500, Pavel Roskin wrote:
> 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:
>
> 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.
I completely agree. The approach we are taking with dadwifi[1] is to
use much of the existing code from madwifi and port it to the d80211
stack. Today dadwifi works in monitor, sta and ap mode.
-David
[1] http://madwifi.org/wiki/DadWifi
>
> --
> Regards,
> Pavel Roskin
>
>
>
> -------------------------------------------------------------------------
> 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.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Madwifi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
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
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.c 2005-06-24 06:41:22.000000000 -0400
+++ madwifi-openhal-fixed/ath/if_ath.c 2006-08-04 14:49:38.000000000 -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.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Madwifi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>
Hi.
> Just in case you want to experiment, i have a working port of ar5k
> that works on madwifi-old before the BSD - HEAD merge...
Just to mention it: madwifi-old is no longer officially supported, and is
a bad ground to start working on IMO (at least for anything that goes
beyond a quick test).
Interested parties should start from trunk instead (which is at r1809 as
of now, by the way), or, even better, from the DadWifi branch. However, it
will require some work to get the OpenHAL working in either of them. I
suggest that related questions and discussions should be directed to the
madwifi-devel list, since they might be of little interest (yet) on netdev
or lkml.
The MadWifi project is happy to provide resources (such as r/w access to
our Subversion repository) to support these efforts, by the way. Please
contact me offlist for details.
Bye, Mike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michael,
>> 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.
>
> Yeah, wanted to hear that. ;)
+1
At least, this way we have a chance to get USB working as well (See http://madwifi.org/ticket/33).
OpenBSD seems to have a working driver (if_uath.c) for these USB WLAN sticks.
Jochen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRVxzGsP9a9GOLSE6AQIeRgf/ZyvmzdhP1+wjVshy2kK0BX+I+lx7y6RO
mMmaVXPnXnHhHE4OLcf9Yrnn6d6i6rS+0CUbw60KgQouuvTFSXEFtSpIYRlXGAyj
krMCj8bEfHhDEN8iYjbjdhP9Nx1wQ//JGyoBVpZZ5+sro6ik7wv70igFeDZ2IWg6
38ycxDzINaV13ZscpwoHzO3NhvcSs9k99Syrh/nR6/pp+3g2vXmrsYR+hy7DMrE/
bSI9y50h8rz6ZCire1ppDwADyBW5B1OondoRkjFYd3L8zNUu8s8xUHZ0Znz6B/cc
yc7jyfQMsBRTUU7VsX3cWuMfA0UGlPn/0MR0+RHRJYHW5bRlStc5Kw==
=Ajsn
-----END PGP SIGNATURE-----
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.
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