Atheros Hardware Abstraction Layer Source Is Released

chrb writes "With the recent discussion here on proprietary blobs in the Linux kernel, it's nice to see that today Sam Leffler has released the source for the Atheros Hardware Abstraction Layer under the ISC license, which is both GPL and BSD compatible. The Atheros chipset is used in many laptops, so this is another important step towards running a completely free distribution."

YAY

I have a Macbook from just over a year ago, and it uses a Atheros wireless card, and it's the biggest pain to get running in Linux. Hopefully, with the Source released, it will be easier in the future to get the wireless working on this model of computer.

Interesting

This is interesting, as there are three Atheros drivers, all different. Madwifi uses the HAL. Ath5 is in the Linux trunk and doesn't (I think). Ath9 was developed by Atheros and probably uses the HAL but I didn't check. Sam was mostly interested in this because he wanted to work on mesh networking - it's good to see he's still involved.

The argument about BLOBs - binary loadable objects in the kernel - is not new, despite Bruce Byfield's recent report. I guess he just doesn't read the kernel list and other distro internal discussions, where this has been going on for a decade. And FSF did not "redefine" anything, they've always held that opinion.

It would be nice to draw a line at the hardware bus, with all above that Open Source and all below that whatever the hardware manufacturer likes because we don't deal with it. But BLOBs break that, because they are both above and below the bus. If we're going to handle the code, we can't really deny that there's a computer there running closed-source code. And given the degree to which wifi firmware sucks the world would be nicer if it was Free Software. Now, we just have to drive some sense into FCC, etc.

Bruce

Re:Interesting

Actually ath9k is fully open source by Atheros.
http://mobile.slashdot.org/article.pl?sid=08/07/26/2138228 [slashdot.org]
No firmware, no HAL, nothing.

I've bought two of the cards to support Atheros even though the drivers arent 100% just yet.
I also have a older b/g card which works superbly.

Re:Interesting

I have a new Acer Aspire One, with Atheros wireless, and have mostly got it running Debian properly - the biggest bugs I'm seeing may be in Debian Lenny rather than anything about Aspire One. A nice thing about this HAL release is that it makes Sam's virtual WAP software unquestionably Free - even from the BSD perspective. Did you ever want to connect to all of the WAPs you can reach at once, and be two or three different WAPs for others at the same time, all without carrying extra hardware? Sam's code can do that.

Being someone who speaks publicly about Open Source, I want to be seen using 100% Open Source. If you're going to talk the talk, you should walk the walk too.

Re:Interesting

i mean it is nice to open source their code, but given that it has pretty much been reverse engineered already, isn't it a bit late!?

Especially since the kernel developers aren't going to let anything with a HAL into Linus' tree, entirely for architectural reasons. But it makes the best version of the driver at the moment fully free.

Sweet

I didn't see this coming, although I have to say I don't keep up with MadWifi news anymore since they fixed 64-bit support for the AR5007 chipset...

Working sleep mode?

Does this mean the sleep function will finally work as it should without draining the batteries? I have yet to see a laptop running Linux go into hibernate mode and not bleed off the batteries.

Re:Working sleep mode?

If you can prove that it bleeds off the batteries more than Linux, we would like to see numbers, please. Linux isn't in charge once the machine is asleep. It would mean that some device is left in a power-drawing mode. I can't say for sure that Atheros has anything to do with this. Are you confusing it with the other HAL on Linux systems?

Re:Working sleep mode?

Oops, I meant to say "more than windows", of course.

Re:Working sleep mode?

ermm, I think the problem here is that the OP is referring to two different things, "sleep" and "hibernate", but unless I am incorrectly remembering my ACPI (which is quite possible), Linux is in fact, if not "in charge once the machine is alseep", at least in charge of correctly putting all various pieces of the system into S3 sleep mode correctly. I know that for a long time my Thinkpad had powerdrain problems in S3 because of incorrectly suspended wifi. For hibernate mode (assuming true write to disk and power off), then of course Linux isn't in charge.

Re:

Yes, I guess the OSPM could leave the wireless interface in a power-draining state.

Re:Working sleep mode?

It means that community developers will be able to write a driver that works as well in any OS as the Windows one, in every way.

It means all those Linux netbooks that were sold with cheap Aths, will soon have completely robust, standards-compliant wireless. And all those sniffing network-trickery programs that the haxors love, will Just Work(tm). And development can proceed with mesh networking on a much wider scope.

Re:Working sleep mode?

Right now, there is a larger team working on madwifi than just Sam, and the kernel team is working on ath5, so I don't think you're right this time.

There is another reason to expect this to result in a code improvement. The same netbooks that have the Atheros wifi often have Intel 3D as part of the chipset. Intel 3D is known to be horrible on Windows. Part of the problem is that desktop vendors don't want Intel 3D to be good, because they want to sell graphics cards. So, Intel has little incentive to make it better.

Except under X, that is. As far as I can tell, it works great under X. The X team at Intel is either not bothered with marketing hold-back; or because the source is public or satisfies a server market, they can justify a need for quality.

ATI will improve over time, and they will probably drive most of it themselves. Open Source will help them do that.

Bruce

Re:Working sleep mode?

Hi, I joined X.org after ATI released docs, and helped add support for an entire line of video cards, including the one I'm using right now to type this.

Your defeatism is kinda silly, if you stop and consider how much work we've done in the open source world.

Re:

The Slashdot article was confusing, and I didn't help. Sorry. It's not firmware in this case.

OpenWRT and DD-WRT porting boosted by this?

I wonder if this could be used to help port OpenWRT over to the atheros chipset. Currently the only routers that OpenWRT (and conversely by that DD-WRT) really work well on are the broadcom chipsets. Many routers that use the Atheros chipset have been written off as impossible to port to. Maybe they could be used if this proves any insight to how they operate.

Re:

When is the last time you've looked at this? The Nanostations [metrix.net], which are atheros based can run OpenWRT, DDWrt, etc. The big thing I see here is that with OSS HAL, maybe adhoc support on atheros will get better. Meraki, FON, and the ACCTON (openmesh.com) routers are all atheros too.

Good news; but blob related?

I was under the impression that the atheros HAL is not a binary blob in the sense the summary refers to, but a program executed on the host CPU [madwifi-project.org]. That makes this even better news than if it were a blob. It is debatable whether or not a system that needs to load a bunch of blobs onto its peripherals at startup is free or not(personally, I'm inclined to say it is, as long as the mechanisms for loading the firmware and interacting with the peripheral are open and the firmware is freely redistributable); but a system with a big binary lump running in kernel space definitely isn't.

It is very encouraging to see progress towards removing one of the most common causes of tainted kernels(probably second only to video card drivers); but it isn't really related to the blob question.

Re:Good news; but blob related?

It was not firmware for downloading into the embedded processor of the wifi device. That came up because of the Bruce Byfield article recently covered here. There are BLOBs that execute on the main CPU, like nVidia's. I'm not sure if this HAL was ever one of those.

Re:

Erm...What wifi chip are you using?

The good thing about manufacturers opening their drivers is you get a completely free distro and its fully functional.

Re:Who is Sam Leffler?

It is nice to have an open source driver released, but it is NOT nice that an individual have to go jump through hoops and write it himself to make it happen.

That's how a lot of them happen. What's worse is when an individual, or team of individuals, work for years to make some proprietary code unnecessary, all of the time knowing that only when they are done will the manufacturer of the proprietary code place it in Open Source.

Re:Who is Sam Leffler?

Unless you're on the Samba team ;)

Re:DVD and Blu-ray

In the UK this stuff is patent free because there are no software patents in England. It depends very much on where you live.

If Canonical made a UK distribution which included all the patented free software it would also create prior art in case of any changes in UK patent law.

Re:Well, this should brighten up Theo's day...

1. If you remove someone else's name and add your own, that's plagiarism, not theft.
2. If you remove someone else's license, and the license doesn't give you permission to do that, that's copyright infringement, not theft.
3. If you add a new license and list yourself as an author, and the old license didn't give you permission to do that, that's copyright infringement, not theft.
4. If you don't enforce your copyright, that's nothing. Copyright gives you the right to sue, if you punt, that's your choice, stop moaning.

Re:Why are there blobs?

You are confusing blobs with firmware. Firmware is software run by the hardware's processor. It used to be stored in ROM, but ROM is expensive, and if the host has a lot of RAM (which any computer does in comparison to a WiFi card) it's cheaper to just give some of the RAM to the device and let it use that instead. This also has the advantage that it's easier to fix bugs in the firmware - just download a new version, rather than replacing the chip (some old cards had the ROM in a socket for doing this, but it was quite rare for anyone to actually do it).

This is not firmware, however, it is a blob. The kernel module originally just took commands from a userspace driver and passed them over the bus, much like the DRI modules. Unlike the DRI driver, the HAL was binary-only. It was originally claimed that this was required by the FCC, since with the source code anyone could modify the driver to push the card out of regulatory compliance. It was a far from satisfactory solution, however, since it meant that no one could fix the blob, and it was limited to x86-only.