Kernel-Log – Was 2.6.39 bringt (1): Netzwerk-Treiber und -Infrastruktur

Seite 2: WLAN-Treiber, Staccato

Inhaltsverzeichnis

Aufgenommen haben die Kernel-Entwickler den WLAN-Treiber rtl8192cu für die Realtek-USB-WLAN-Bausteine RTL8192CU und RTL8188CU (u.a. 1, 2). Genau wie der bei 2.6.38 integrierte Realtek-WLAN-Treiber rtl8192ce setzt er auf den WLAN-Stack des Kernels auf und wurde maßgeblich von Realtek selbst entwickelt. Ältere unter der GPLv2 stehende WLAN-Treiber von Realtek brachten einen eigenen WLAN-Stack mit und schafften es daher zumeist nur in den Staging-Zweig. In der Praxis sind diese Treiber häufig hakelig, da manche Distributionen Staging-Treiber nicht mitliefern; zudem zeigen manche dieser Treiber Probleme beim Zusammenspiel mit Programmen wie dem NetworkManager.

Die Integration der beiden Treiber in den Kernel hat Realtek allerdings nicht selbst vorangetrieben; vielmehr ist sie maßgeblich dem Kernel-Hacker Larry Finger zu verdanken, der einige Aufräumarbeiten vornahm und zwischen Realtek und anderen WLAN-Treiber-Hackern vermittelt. Durch diese Bestrebungen scheint sich die Lage bei Treibern für Realtek-WLAN-Chips langsam zu bessern; ob es für die derzeit nur von Staging-Treibern untersüttzten Realtek-Chips auch noch bessere Treiber geben wird, steht aber noch in den Sternen.

Den Treiber rt2800pci haben die Entwickler um experimentelle Unterstützung für den Ralink-WLAN-Chip RT5390 erweitert; diese ist allerdings als noch nicht funktionstüchtig gekennzeichnet und richtet sich für erste nur an Tester und Entwickler. Genau wie bei den Realtek-Treibern dürfte sich auch die Lage bei WLAN-Treiber für Bausteine von Ralink in Zukunft verbessern, da das Unternehmen neuerdings an den im Rt2x00-Projekt entstandenen Treibern direkt mitarbeitet, die vor langer Zeit zum Kernel stießen. Das berichtete Greg Kroah-Hartman vor einigen Wochen in seinem Blog; ähnlich wie Realtek hatte auch Ralink lange eigene Treiber entwickelt, die es aufgrund von Qualitätsmängeln nur bis in den Staging-Zweig geschafft hatten.

Die Treiber vom Rt2x00-Projekts entstanden weitgehend unabhängig von jenen, die Ralink entwickelt hat; mittlerweile unterstützen Erstere viele Chips genauso gut oder besser. Die Staging-Treiber rt2860sta und rt2870sta für [Update, 20110414-1730]USB-[/Update] WLAN-Chips von Ralink dürften daher bei 2.6.40 vermutlich aus dem Kernel fliegen, denn sie sprechen WLAN-Bausteine an, die die Rt2x00-Treiber mittlerweile unterstützen (1, 2). Wer mit Letzterem noch Probleme hat und daher einen der beiden Staging-Treiber einsetzt, sollte das den Kernel-Hackern zügig melden, damit sie die Probleme beseitigen können oder den Rauswurf vertagen.

Wie schon bei 2.6.37 und 2.6.38 haben die Kernel-Hacker den Code für 802.11n-Chips von Broadcom im Treiber b43 weiter ausgebaut, wodurch dieser nun auch 802.11n-PHYs ab der dritten Generation anspricht (u. a. 1, 2) Einen guten Überblick, welche Broadcom-Chips der Treiber dadurch nun erstmals oder besser unterstützt, liefern die aktuelle Wiki-Seite zum Treiber sowie die Änderungen, die seit Mitte März an ihr vorgenommen wurden; die Bausteine BCM4321 und BCM4322 zählen nun etwa zu den teilweise unterstützten Chips. Die Bausteine BCM4313, BCM43224 und BCM43225 kann der Treiber aber weiterhin nicht ansprechen; die Wiki-Seite listet aber auch, welche dieser Chips der proprietäre Treiber wl oder die von Broadcom selbst vorangetrieben Staging-Treiber ansprechen.

Der Treiber iwlwifi spricht nun auch die WLAN-Chips aus Intels 2000er-Serie an (u. a. 1, 2). Um die Pflege dieses WLAN-Treiber für neuere WLAN-Bausteine von Intel zu erleichtern, haben die Entwickler die Unterstützung für die Baureihen IPW3945 (802.11g) und IPW4965 (802.11n) in den neu angelegten Treiber iwlegacy auslagert.

Der einige USB-Chips von Atheros ansprechende Treiber ar9170usb soll bei 2.6.40 aus dem Kernel fliegen, da der bei 2.6.37 integrierte Treiber carl9170 ihn ersetzt.

  • Nach der bei 2.6.37 integrierten Basis-Infrastruktur zum Betrieb als Xen-Host (Dom0) folgt mit Kernel 2.6.39 das Netzwerk-Backend, über das die Frontend-Treiber in Xen-Gästen (DomU) mit anderen Systemen kommunizieren. Das Storage-Backend fehlt allerdings weiterhin, daher wird kein sinnvoller Betrieb als Dom0 möglich sein, ohne weitere Patches einzubinden.
  • Zum Netzwerk-Stack stieß der Paket-Scheduler CHOKe ("CHOose and Kill" oder "CHOose and Keep"). Er basiert auf dem Algorithmus [Update, 20110414-1730] Random Early Drop (RED; im Commit-Kommentar und dadurch in einer früheren Version dieses Artikels fälschlicherweise als "Random Exponential Drop" bezeichnet) [/Update] und ist primär für Router und Bridges interessant, um Überlastungen beziehungsweise Staus zu vermeiden; Hintergründe dazu liefert LWN.net in "The CHOKe packet scheduler". Neu ist auch der Stochastic Fair Blue (SFC) scheduler, der Ideen der 1999 publizierten Forschungsarbeit "BLUE: A New Class of Active Queue Management Algorithms" aufgreift.
  • Der Bluetooth-Code beherrscht nun die in der Bluetooth-Spezifikation 4.0 definierten Low Energy (LE) Connections. Neu dabei ist auch der Bluetooth-Treiber btwilink für den WiLink7 von Texas Instruments. Zudem gab es eine ganze Reihe von Nokia-Entwicklern eingebrachte Detailverbesserungen im Bluetooth-Code, zu denen die Links im Artikelabschnitt "Die kleinen Perlen" führen.
  • Der Netzwerk-Stack bietet ab 2.6.39 Mechanismen, um einige Aufgaben für QoS (Quality of service) an Hardware auszulagern.
  • USB-Netzwerk-Chips mit einer global eindeutigen MAC-Adresse weist der Kernel fortan mit "eth" beginnende Namen zu; für andere, typischerweise zur Point-To-Point-Kommunikation eingesetzte Chips bleibt es beim Präfix "usb".
  • Der USB-NIC-Treiber smsc95xx unterstützt jetzt auch die SMSC-Chips LAN9530, LAN9730 und LAN89530.
  • Der Treiber wl12xx für die WLAN-Bausteine wl1271 and wl1273 von Texas Instruments beherrscht nun auch den Betrieb als Acess Point (AP) (u. a. 1, 2, 3, 4, 5).
  • Zum Kernel stieß auch der Treiber c_can für den C_CAN Controller von Bosch, dessen Logik in einigen Produkten von ST Microelectronics steckt.
  • Der für Encapsulating Security Payload (ESP) zuständige Funktionen erweiterten die Kernel-Hacker um Unterstützung für die in RFC 4303 spezifizierten IPsec Extended Sequence Numbers (ESN) (1, 2).
Git-Pull-Requests 1 2 3 einige Änderungen 2.6.37 2.6.38