Kernel wireless maintainer John Linville outlined the past, present, and future
of the Linux wireless stack on the first day of this year's Ottawa Linux Symposium. In
his presentation, he ranged from early efforts, which were "a sore
spot for Linux" to the future where it is likely that Linux will have
support for some features before "that other OS". Along the
way, he looked at various issues that wireless support in Linux faces,
including vendor participation, suspend and resume, and regulatory issues.
Linville has been the maintainer Linux wireless for two and a half years since
being recruited into the job by David Miller and Jeff Garzik. When he took
over, wireless support was in disarray, as there were competing stacks to
support different hardware. Users were faced with lots of pain in getting
things working when "they just want their hardware to work"
said Linville. Since that time, things have greatly changed.
The original wireless hardware was what is called "Full MAC hardware",
where the implementation of the wireless protocols was handled by the
hardware, generally in firmware. The drivers made these devices appear to
be regular wired ethernet devices, though they did require some special
configuration for SSID and the like. Because the hardware would enforce
various regulatory requirements, vendors would generally work with the
community in order to support the hardware.
All of that changed with the advent of "Soft MAC hardware"—which
Linville likened to winmodems—where the CPU implements most of the
protocol. It is a cheaper solution for vendors, but it requires an 802.11
stack for the kernel. The ieee80211 drivers came along to support
the Intel Centrino wireless hardware, but they only supported those few
devices. Johannes Berg added the ieee80211softmac driver that
added some additional hardware support, but it was a kludgy solution.
Since then, Linville said, folks have realized that it was "sort of a
mistake to go down that road".
Enter the Devicescape stack. It was a feature rich 802.11 stack for Linux
that was popular with developers. After some locking and SMP problems were
resolved, it was merged into 2.6.22 as the mac80211 driver. Once
that happened, wireless drivers
started using it, to the point where Linville showed a chart of the current
drivers, almost all of which use mac80211. "It's been a boon
to us to pick up the mac80211 code."
One notable driver that does not support mac80211 is the libertas
driver for the OLPC. Unlike most other current devices, it is a Full MAC
device with special requirements. It has support for power saving modes
that do not yet exist in mac80211. Because it is a mesh-networking
device that still participates in forwarding network traffic when the
system is powered down, it has needs that are not yet supported.
Drivers in progress was the next topic Linville addressed. Several of
these are in need of developers to work on them, specifically for the Airgo
chipset and Atmel USB chipset. The TI chipset drivers have had some
questions raised about the reverse engineering process and may require a
legal vetting similar to what the SFLC did for ath5k. Marvell is
sponsoring development of a mac80211 based driver for its
hardware. This driver may also support 802.11n which allows for greater range
and higher speeds than current-generation 802.11.
Using data from LWN, Linville looked at the activity level of the wireless
development in Linux. He was amazed to note "how much of the 2.6.26
kernel came through this laptop". Using his Signed-off-by as a
proxy for wireless LAN commits, he noted 4.3-5.6% of the kernel commits in
the last three releases (.24 through .26) were for wireless. In each
kernel, wireless was either the fourth or fifth highest number of commits.
The compat-wireless-2.6 project is aimed at supporting newer hardware in
older kernels. Because folks are wary of running kernel.org kernels or
their distribution supports an older kernel—but they want to run with the
latest hardware—the project backports wireless drivers to kernels as
old as 2.6.21. It is a set of scripts and patches that build against the
user's kernel. Unfortunately, the project may not last much longer as the
multiqueue changes that have been merged for 2.6.27 may change the drivers
enough that they will be infeasible to backport.
At the top of the list for new features is removal of the wireless
extensions in favor of the new cfg80211 mechanism. According to
Linville, "nobody likes wireless extensions, and nobody likes the
tools". The wireless extensions have vague semantics, can have
problems with race conditions, and because they are implemented by
ioctl() calls, they encourage duplication of code in multiple
drivers. cfg80211 will bring a much cleaner API along with
fixing some existing bugs like the 31 character limit for SSIDs.
Access point (AP) mode is another feature that is coming. Typically, APs
use similar or identical hardware to that in wireless MACs. For Soft MAC
hardware, all that is needed is support on the CPU side for AP mode, which
is coming for mac80211. Mesh networking, which has been
popularized by the OLPC project, is also coming to mac80211.
Cozybit has provided an implementation which will allow Linux to have a
feature unavailable for Windows.
Areas that are needed, but are not yet being worked on was next on
Suspend and resume support is "flawed for mac80211
due to connection management issues". Because mac80211 is
unaware of suspend and resume, drivers must work around it by de-registering
and re-registering with it, which can be slow. Adding support for suspend
is on the list, as is supporting power saving modes.
Linville went on to discuss three big issues that are largely outside of
the control of the wireless hackers: firmware licensing, vendor participation,
and regulatory concerns. Because drivers for Windows come with the
firmware in the driver, many hardware vendors do not license the firmware
blob separately. This means that it is unclear what can be done with those
blobs. Certain vendors—Intel and Ralink were specifically called
out—provide liberal licenses for their firmware. Users are
encouraged to "vote with your dollars" by purchasing devices
that either do not require firmware or that have a clear, free software
Another consideration when deciding which vendors to support is whether
they are engaged with the community. For the most part, all vendors but
Broadcom are working with the wireless hackers by providing documentation
and/or source code. Some are even providing
dedicated developers to work on Linux drivers—Intel was the first,
but both Atheros (which just released a driver for its ath9k
hardware) and Marvell have also begun doing that.
Government regulations about what can and cannot be done in the unlicensed
frequencies used by wireless are a concern that is frequently cited by
vendors when refusing to work with the community. Unfortunately, their
concerns are not completely without merit as hardware vendors are expected
to ensure compliance with the regulations. "Non-compliance could be
a huge loss" for those companies. As Linville points out, though,
most vendors find a way to support Linux drivers.
In answer to a question, Linville said that most WiMAX and 3G wireless
devices are Full MAC designs, so there should be little or no regulatory
concern, which, in turn, means that Linux support should not be much of a
problem—at least until Soft MAC devices come along. Overall, Linux
wireless has come a long way, but there is lots still to do. One gets the
sense that the wireless team is up to the task.
to post comments)