Kernel comment: The obstacle course of cooperation

by Thorsten Leemhuis

Broadcom has spent a year working on its open source driver for WLAN/Wi-Fi hardware to fulfill the quality demands of the kernel developers, but now they may not even want it any more.

When it presented Brcm80211 a year ago, Broadcom became the last major manufacturer of WLAN chips for notebooks to get into developing open source drivers for its own WLAN components. The company was praised for this step, and Brcm80211 became a part of the kernel after only a few weeks. But the code landed in the staging area because it did not fulfil the quality demands of kernel developers. The firm then spent part of the past 12 months fulfilling these requirements; now, we have the Brcmsmac and Brcmfmac drivers.

At the same time, Rafał Miłecki improved the B43 driver that has been in the kernel for some time. The driver originally only supported older Broadcom WLAN chips, and Miłecki added support for numerous components that Brcmsmac addresses.

Normally, Linux developers try to avoid having multiple drivers or a series of closely related components in the kernel for a single chip so as not to unnecessarily tie up developer resources; furthermore, users could be confused and decide to switch to a second driver instead of reporting the problems they are having. But no-one objected to Miłecki's work on B43 because Brcmsmac was a staging driver, which some WLAN developers don't really take seriously.

On the Linux Wireless mailing list, the developers recently discussed a solution for the two-driver problem after Broadcom developers asked whether their driver was ready to leave the staging area. At present, no solution is in sight, but it looks like a lot of the work that either Miłecki or the Broadcom developers did will have been in vain.

In retrospect, it seems that some of the fruitless labour could have been easily avoided. But as with so many disputes, everyone involved bears some of the blame for failing to act towards a common goal either by not paying attention or by not coordinating their actions. The result is a tricky situation that no one wanted.

Having said that, a significant portion of the blame lies with Broadcom. The first mistake was developing Brcm80211 behind closed doors so it would draw a lot of attention when presented; all of the subsequent mistakes probably stem from that one. Because, even when the driver was presented some people said that Broadcom should have simply added support for more recent WLAN components to B43, just as Miłecki eventually did – but then the firm would not have received as much positive press.

Broadcom not only ignored offers to contribute to B43, but also failed to keep developing the driver once it was established. The public development process ensured that it was by no means a secret that Miłecki was working on the driver code for recent Broadcom chips. Miłecki even occasionally told Broadcom developers what he was doing, but they either failed to understand the importance or simply ignored the problem, as a number of emails show.

However, Kernel developers should not throw the first stone. For instance, staging maintainer Greg Kroah-Hartman was unaware of the dual-driver problem until recently; otherwise, he certainly would have insisted on a solution sooner. Other kernel developers probably also realised what was going on but didn't ask for a solution.

And these are only a few of the mistakes made on both sides. Now this will probably lead to disappointment or frustration for the developers of one of the drivers, and it also delays getting a single driver accepted. The whole issue puts kernel programmers in a bad light, which may well deter some firms that were planning to get involved in the development of Linux drivers for their hardware.

We can only hope that everyone involved will learn their lesson. Companies should not develop drivers behind closed doors, like they do for Windows, and hope that kernel developers will receive them with open arms. Instead, firms should adapt themselves to the existing developer structures for the kernel. Everyone involved – including users – would benefit not only in the long-term, but often even in the short term. The other kernel developers need to monitor new developers and firms so that tricky situations like the one described here can be quickly identified and prevented.

Kernel developers should not, however, give up their demand for "no more than one driver per component" as this approach prevents a lot of problems, otherwise, firms would just start supplying their own Linux software for their WLAN components in order to provide "added value" – and, of course, to present their corporate logo once again.

Thorsten Leemhuis is the author of Kernel Log, published on The H and heise Open in Germany, which tracks, in detail, developments and advances in the Linux kernel and its ecosystem of free and open source software. Editions of Kernel Log can be found by using the search function at The H Open Source.