Kernel-Log – Was 2.6.37 bringt (3): Netzwerk- und Storage-Hardware

Zahlreiche Änderungen am Netzwerk- und Storage-Code sollen die Arbeitsgeschwindigkeit steigern und die Hardware-Unterstützung verbessern. Neu sind etwa ein PPTP-Stack, verschiedene Treiber für WLAN-Hardware von Atheros, Broadcom und Realtek und Code für Festplatten, die logisch mit 4 KByte großen Sektoren arbeiten.

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Lesezeit: 23 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In einer Antwort auf die Freigabe-Mail von Linux 2.6.37-rc5 vergagenen Woche rechnete Tony Luck hoch, dass die Freigabe von 2.6.37 noch vor Weihnachten durchaus im Bereich des Möglichen liege, da diesmal alles sehr gut laufe. Torvalds sieht das ähnlich, aber nicht ganz so rosig; und selbst wenn alles glatt laufe, würde vermutlich kaum jemand wollen, dass das Merge Window in den Urlaubstagen rund um den Jahreswechsel offen sei. Er denkt daher, dass er den Kernel 2.6.37 Anfang Januar freigeben wird, sofern nicht noch Probleme auftauchen, die eine weitere Verzögerung erfordern.

Das Kernel-Log setzt derweil die Mini-Serie "Was 2.6.37 bringt" mit einer Beschreibung der Neuerungen rund um Treiber und Infrastruktur für Storage und Netzwerk-Hardware fort. Der erste Teil der Serie hatte sich bereits mit den Änderungen rund um Grafik-Hardware beschäftigt, der zweite mit denen rund um Dateisysteme; folgen werden in den kommenden Wochen noch Artikel zu Architektur-Code, Treibern und der sie umgebenden Infrastruktur.

Zum Netzwerk-Subsystem stieß eine Kernel-Implementierung des für VPNs genutzten Point-to-Point Tunneling Protocols (PPTP); wie der Commit-Kommentar erläutert, soll sie deutlich schneller arbeiten und die CPU weniger belasten als existierende Userspace-PPTP-Stacks. Nutzen lassen sich die neuen Kernel-Funktionen mit accel-pptp.

Neu dabei ist auch der Treiber bna für 10Gb-Ethernet-Chips 1010 und 1020 von Brocade. Der Treiber bnx2x unterstützt nun auch den Broadcom 57712; zum Kernel stieß ferner ein Netzwerk-Treiber für die LAN-Chips der Tile-Architektur sowie LAN- und CAN-Treiber für Intels Embedded-PCH Topcliff. Der Kernel beherrscht nun auch das CAIF Shared Memory Transport Protocol der U5500-Chips von ST Ericsson (STE) (1, 2).

Die Unterstützung für Bluetooth-Elemente von durch ath9k versorgte WLAN/BT-Kombi-Hardware mit Atheros-Chips wurde ausgebaut. Der Kernel kennt nun auch die Bluetooth-Controller im MacBookAir3,1(2), MacbookPro 6,2 und MacbookPro 7,1. USB Autosuspend im Bluetooth-USB-Treiber btusb ist nun standardmäßig eingeschaltet, was die Leitungsaufnahme senken sollte, wenn es nichts zu tun gibt.

Einige weitere wichtige Änderungen nennt Netzwerk-Subsystem-Betreuer David Miller in seinem Haupt-Git-Pull-Request. Dort lobt er zahlreiche von Eric Dumazet eingebrachte und teilweise bei den kleinen Perlen am Ende des Artikels verlinkte Optimierungen rund um Routing-, Neighbour- und Device Handling. Laut Tests sei das Routing dadurch nun schneller, wenn der Routing Cache deaktiviert ist; letzterer werde aber noch für andere Dinge gebraucht, daher können man ihn nicht einfach entfernen. Einige Hintergründe zu den Optimierungen finden sich auch in den Präsentationsfolien des kürzlich von Miller gehaltenen Vortrags "Linux Networking: The RISE of the congestion window, the FALL of the routing cache, and the LOCALITY of packets".

Mit der Kernel-Version 2.6.37 haben die Entwickler den Treiber carl9170 für die Atheros-Chips AR9170 in den Linux-Kernel integriert (u. a. 1, 2, 3, 4, 5). Diese Bausteine betreuten bislang die Treiber ar9170usb und otus. Ursprünglich hatte Ersterer den im Staging-Bereich angesiedelten Otus-Treiber ersetzen sollen, konnte jedoch bei Funktionsumfang, Geschwindigkeit, Stabilität und Qualität nie zu Otus aufschließen. Das soll Carl9170 gelungen sein, daher wurde Otus rausgeschmissen; mittelfristig dürfte ar9170usb das gleiche Schicksal ereilen.

Es gab noch einige andere für Netzwerk-Hardware relevante Änderungen im Staging-Bereich, in dem Treiber und andere eigenständiger Code liegt, der den Qualitätsansprüchen seiner Entwickler oder der Kernel-Hacker nicht genügt. Der neu aufgenommene Staging-Treiber rtl8712 ersetzt den für USB-802.11n-Chips von Realtek geeigneten Treiber rtl8192su; beiden nutzen einen eigenen WLAN-Stack, was einer der Gründe für die Einordnung in Staging-Zweig ist. WLAN-Treiber-Entwickler Larry Finger deutet allerdings an, das Realtek sich neuerdings mehr Mühe bei der Entwicklung von Linux-Treibern gibt.

In diesem Bereich landete auch der von Broadcom selbst entwickelte Open-Source-Treiber brcm80211, der einige 802.11n-WLAN-Bausteine von Broadcom anspricht. Wie schon zur Vorstellung des Treibers im September stehen unter anderem Unterstützung für Stromspartechniken oder Datenverschlüsselung durch den WLAN-Chip auf der Todo-Liste. Das gilt auch für das Funken mit 40 MHz breiten Kanälen – ein optionales Feature des 802.11n-Standards, das jedoch erforderlich ist, um die maximale Brutto-Datenrate von 300 MBit/s zu erreichen.

Unter den "kleinen Perlen" am Ende des Artikels finden sich auch einige Commits, welche den Code zur noch rudimentäre 802.11n-Untersüttzung im Treiber b43 verbessert, der andere WLAN-Bausteine von Broadcom anspricht. Diese Arbeit stammt größtenteils von Rafał Miłecki, der kürzlich in einem Blog-Eintrag beschrieb, dass eine weiter verbesserte Version des B43-Treibers nach einem Jahr Arbeit nun endlich auf dem BCM4328 arbeite. Miłecki erklärte zudem auf Nachfrage, dass sich die vom brcm80211 unterstützten Chips von Aufbau stark von jenen unterscheiden, die b43 anspricht – viele Elemente zum Ansprechen des PHYs seien aber ähnlich, daher glaubt er, dass b43 langfristig weiter verbessert wird und dann auch die derzeit von brcm80211 unterstützten Chips ansprechen wird.

Der für Schreibbarrieren zuständigen Code arbeitete nach Ansicht einiger Kernel-Hacker bislang an einigen Stellen übervorsichtig. Eine größere Umstrukturierung soll dem ein Ende machen und verlagert die Verantwortung zum Ordnen der Schreibreihenfolge größtenteils an den Dateisystemcode, was den Datendurchsatz bei bestimmten Aufgaben deutlich steigern soll. Hintergründe zu diesem Thema liefert LWN.net im Artikel "The end of block barriers", eine LKML-Diskussion und die Kommentare zu einigen die Änderung umsetzenden Commits (1, 2, 3, 4)

Über Control Groups (Cgroups) lässt sich nun auch der maximale Durchsatz von Datenträgern limitieren/drosseln; Details liefern einige der Commit-Kommentare (1, 2, 3, 4) und die aktualisierte Dokumentation. Einige Änderungen am CFQ-I/O-Scheduler sollen dessen Performance steigern, wenn ein Fsync ("File Synchronize") bei kleinen Dateien abgearbeitet wird. Der Code zum Einbinden der Root-Partition kann die richtige Partitionen nun mit Hilfe eines UUID (Universally Unique Identifier) finden, wenn man den Kernel mit einem Parameter wie "root=PARTUUID=hex-uuid" dazu anweist.

Das Libata-Subsystem arbeitet nun auch mit Festplatten zusammen, die nicht nur physisch, sondern auch logisch mit Sektoren arbeiten, die nicht 512 Byte groß sind; getestet hat der Entwickler den Code mit einem "Engineering Sample" eines mit 4K-Sektoren arbeitenden Datenträgers von Hitachi GST. Durch die neue Libata Transport Class exportiert der für ATA-Adapter zuständige Kernel-Code fortan weit mehr ATA-Interna via Sysfs. Der Kernel unterstützt nun zudem IDE-R Devices von Intels AMT (Active Management Technology); um verschiedene Probleme zu beseitigen haben die Libata-Entwickler den Code für Link Power Management neu implementiert.

Im SCSI-Subsystem und dem darauf aufbauenden Libata-Code gab es einige größere, erst für die dritte Vorabversion von 2.6.37 integrierte und zuvor auf der LKML diskutierte Änderungen. Sie bauen die Locking-Mechanismen um, was manche Treiber beschleunigen soll (u. a. 1, 2)

Der neue Treiber cxgb4i bietet iSCSI Connection Acceleration bei T4-Produkten von Chelsio. Der Infiniband-Stack und der Treiber mlx4_ib bieten nun Unterstützung für das auch als InfiniBand-over-Ethernet/IBoE (u. a. 1, 2). Die Technik wird eigentlich RDMA over Converged Ethernet (RoCE) genannt, der Betreuer des Infiniband-Codes bevorzugt jedoch InfiniBand-over-Ethernet, wie er in zwei Blog-Einträgen zu den Neuerungen erläutert (1, 2)

Viele kleinere, aber keineswegs unbedeutende Neuerungen finden sich in der folgenden Liste mit den englischen Commit-Überschriften der jeweiligen Änderung. Die Einträge verlinken genau wie viele der Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs mit den "offiziellen" Kernel-Quellen auf Kernel.org. Der über diese Links angezeigten Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderungen.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien, welche die Hilfetexte und Konfigurationsoptionen enthalten, die bei der Kernel-Konfiguration über "make menuconfig", "make xconfig" und ähnliche Werkzeuge angezeigt werden. Ein "D" steht bei Patches, die die Dokumentation verändern, die im Kernel-Zweig unterhalb von Documentation/ liegt. Ein "N" weist Änderungen aus, die eine neue Datei anlegen. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: eine "1" steht etwa für Änderungen, die inklusive Kommentar zwischen 10 und 20 KByte groß sind, eine "2" für solche, die zwischen 20 und 30 KByte Umfang haben; Änderungen ohne Zahl sind kleiner als 10 KByte, Patches mit einer "9" hingegen 90 KByte oder größer.

LAN

WLAN

Various

Block Layer, DRBD, Infiniband, MD ...

Barrier Rewrite

Libata

MFD, MMC, MTD...

SCSI

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl).

(thl)