Die Woche: Zusammenarbeit mit Hindernissen

Broadcom hat ein Jahr Arbeit investiert, um mit seinem Open-Source-Treiber für WLAN-Hardware die Qualitätsansprüche der Kernel-Entwickler zu erfüllen. Die wollen den Treiber jetzt aber vielleicht gar nicht mehr haben.

In Pocket speichern vorlesen Druckansicht 47 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Thorsten Leemhuis

Mit der Vorstellung von Brcm80211 stieg Broadcom vor einem Jahr in die Entwicklung von Open-Source-Treibern für die eigene WLAN-Bausteine ein – als letzter der großen Hersteller von WLAN-Chips für Notebooks. Das Unternehmen wurde für diesen Schritt gelobt und schon nach wenigen Wochen stieß Brcm80211 zum Kernel. Der Code landete allerdings im Staging-Bereich, weil er den Qualitätsansprüchen der Kernel-Entwickler nicht gerecht wurde. Um sie zu erfüllen, hat das Unternehmen in den vergangenen 12 Monaten einige Arbeit investiert, aus der die Treiber Brcmsmac und Brcmfmac hervorgingen.

Parallel dazu hat Rafał Miłecki den schon länger im Kernel enthaltenen Treiber B43 verbessert. Dabei hat er den Treiber, der ursprünglich nur mit älteren Broadcom-WLAN-Chips umgehen konnte, auch um Unterstützung für mehrere Bausteine erweitert, die Brcmsmac anspricht.

Nun vermeiden es die Linux-Entwickler es normalerweise, mehrere Treiber für einen Chip oder eine Reihe eng verwandter Bausteine im Kernel zu haben, weil das unnötig Entwicklerressourcen bindet, Nutzer verwirrt oder Anwender zum Wechsel auf den Zweittreiber verleitet, statt Probleme zu melden, die sie plagen. Bei Miłecks Arbeit an B43 erhob aber niemand Einspruch, weil Brcmsmac ein Staging-Treiber ist, die von einigen der WLAN-Entwicklern nicht so recht für voll genommen werden.

Auf der Mailingliste Linux-Wireless diskutierten die Entwickler kürzlich über eine Lösung für die Zwei-Treiber-Problematik, nachdem ein Broadcom-Entwickler fragte, ob ihr Treiber weit genug gereift sei, um den Staging-Bereich zu verlassen. Bislang ist keine Lösung absehbar; aber es sieht so aus, als ob letztlich ein erheblicher Teil der Arbeit von Miłecki oder den Broadcom-Entwicklern umsonst gewesen sein wird.

Mehr Infos

Hintergründe

Weitere Details zur den beiden Treibern für neuere Broadcom-WLAN-Chips liefern der erste Teil der Kernel-Log-Mini-Serie "Was 3.1 bringt" oder der englische LWN.net-Artikel "Broadcom's wireless drivers, one year later".

Im Nachhinein betrachtet hätte sich die dadurch entstandene Verschwendung von Arbeitszeit leicht vermeiden lassen können. Aber es ist wir bei vielen Ehestreitigkeiten: Schuld liegt bei allen Beteiligten, die durch Unachtsamkeit oder ungeschicktes Handeln ein eigentlich gemeinsames Ziel verfehlen – statt dessen entstand eine verfahrene Situation, die keiner will.

Ein erheblicher Teil der Schuld liegt allerdings bei Broadcom. Heimlich still und leise Brcm80211 zu entwickeln und dann öffentlichkeitswirksam vorzustellen war der erste Fehler, der vielleicht alle anderen erst ausgelöst hat. Denn schon bei der Vorstellung gab es Stimmen, die forderten, Broadcom hätte besser gleich den B43-Treiber um Unterstützung für neuere WLAN-Bausteine erweitern sollen, wie es Miłecki später getan hat – dafür hätte das Unternehmen aber sicher in der Öffentlichkeit nicht so viel positive Aufmerksamkeit erhalten.

Broadcom hat die Vorschläge zur Mitarbeit an B43 nicht nur ignoriert, sondern auch die Entwicklung des etablierten Treibers nicht verfolgt. Durch den öffentlichen Entwicklungsprozess war es nämlich keineswegs ein Geheimnis, dass Miłecki an Treibercode für neuere Broadcom-Chips gearbeitet hat. Miłecki hat die Broadcom-Entwickler sogar hier und da auf seine Arbeit hingewiesen; die haben die Tragweite aber nicht erkannt oder das Problem ignoriert, wie manche Mails zeigen.

Aber auch die Kernel-Entwickler müssen sich an die eigene Nase fassen. So hat auch Staging-Betreuer Greg Kroah-Hartman von der Zwei-Treiber-Problematik bis vor kurzem nicht gewusst – sonst hätte er sicher früher auf eine Lösung gedrängt. Andere Kernel-Entwickler dürften die Problematik ebenfalls erkannt haben, ohne eine Klärung herbeizuführen.

Das sind nur einige der auf beiden Seiten begangenen Fehler. Die führen nun wohl bald zu Enttäuschungen oder gar Frustration bei Entwicklern eines der Treiber; außerdem verzögert es die Entstehung eines allseits akzeptierten Treibers. Das Ganze wirft zudem ein schlechtes Licht auf die Kernel-Programmierer – das dürfte manche Unternehmen abschrecken, die sich an der Entwicklung von Linux-Treibern für ihre Hardware beteiligen wollen.

Man kann nur hoffen, dass alle Beteiligten Lehren aus der Sache ziehen. Unternehmen sollten nicht in Windows-Manier Treiber unter Ausschluss der Öffentlichkeit entwickeln und hoffen, von den Kernel-Entwicklern mit offenen Armen empfangen zu werden. Vielmehr müssen Hersteller sich in bestehende Entwicklerstrukturen beim Kernel einbringen. Davon profitieren alle Beteiligten und die Anwender nicht nur langfristig, sondern häufig schon sehr schnell. Die Kernel-Entwickler andererseits müssen neue Entwickler und Unternehmen stärker an die Hand nehmen, um das Entstehen verfahrener Situationen wie die bei den Broadcom-Treibern frühzeitig zu erkennen und zu vermeiden.

Die Qualitätsansprüche und den Ansatz "Maximal ein Treiber für ein Bauteil" sollten die Kernel-Entwickler aber keineswegs aufgeben, denn der vermeidet viele Probleme – sonst würden die Hersteller nachher auch unter Linux damit anfangen, eigene Software zum Verbinden mit WLANs mitzuliefern, nur um ein vermeintliches "Added Value" zu bieten, bei dem sie ihr Firmenlogo nochmal präsentieren können. (thl) (thl)