SFLC: OpenBSD Atheros driver is clean

I've been waiting on this one for a while myself.

Basically, the job of a wireless driver should be to send and receive 802.11 packets. Presenting this to the userspace should be done by the 802.11 stack.

The networking in Linux is implemented through network devices. A single network device is typically one physical device connected to one subnet on one medium with one packet queue. Note the inherent overload of functions - the same interface represents hardware, a subnet, a medium and a network queue.

An advanced 802.11 device can act as one physical device on one medium (radio channel) with multiple subnets (virtual APs and WDS connections). The packet queue is common on the physical, but users may want to regulate it on the subnet level as well.

The question is basically how we want to map this to the traditional network device paradigm. I understand that d80211 associates the physical device and the network queue to the master interface and the medium to the "wiphy", whatever it is.

It's desirable to have one interface representing the common part of the wireless device. If we move everything to wiphy, we lose control over the queue because it's done on the network interface level. If we move everything to the master device, we won't lose anything. However, Johannes seems to dislike having a network interface without the ability to send or receive packets. Unfortunately, the alternative is a major surgery of the networking to decouple queue management from the network devices.

In his efforts to understand how the ipw3945 driver controls the firmware, Damien found that the binary daemon was simple to bypass, offering no real control. "I was able to make the daemon think it was in another regulatory domain," he explained, "just by adding a few lines of code into the GPL'd part of the driver." The binary-only daemon is described as necessary due to FCC regulations, causing Damien to retort, "I think Intel (and Atheros) use FCC rules as a pretext to hide intellectual property in the binary-only portions of their drivers." He went on to explain that the Intel regulatory daemon, as well as the Atheros HAL, implement a number of complex algorithms, including automatic calibration of the radio power based on temperature variations, and dynamic tuning of the radio sensitivity based on received signal strength. "These algorithms go far beyond the simple enforcement of regulatory compliance," he added, "and can really make the difference by extending the operating range of the adapter, improving throughput in various environmental conditions, and reducing power consumption. That is why vendors want to keep these algorithms secret.