Kernel-Log: Eindeutige Namen für Netzwerkschnittstellen
Zukünftig soll ein Programm für eine vorhersagbare Benennung von Netzwerkports sorgen – "em1" und "pci2#1" statt "eth0" und "eth1". Im Rahmen der Vorstellung einiger neuer Kernel-Versionen geben wir einen Überblick über die wichtigsten Stable- und Longterm-Serien.
- Thorsten Leemhuis
Bereits seit Jahren wirbt Matt Domsch für Lösungen, die für verlässliche und vorhersagbare Namen von Netzwerkschnittellen sorgen sollen – bei Systemen mit mehreren Netzwerkbuchsen entscheiden derzeit die Ladereihenfolge der Treiber und die Antwortzeiten der Hardware mit darüber, ob ein bestimmter Port als eth0 oder eth1 im System auftaucht. Diesem Ziel scheint Dells Technology Strategist nun einen großen Schritt näher gekommen zu sein: Wie der auch bei DKMS und im Fedora-Projekt involvierte Entwickler in seinem Blog detailliert beschreibt, wird das im Mai erwartete Fedora 15 ein von ihm mit voran getriebenes Bezeichnungsschema nutzen, bei dem Udev zur bei der Benennung von Netzwerkgeräten auf das maßgeblich von Dell-Mitarbeitern entwickelte Programm "Biosdevname" zurückgreift. Laut Domsch wollen auch andere Distributionen diese Lösung übernehmen.
Dem ersten Netzwerk-Port auf dem Mainboard soll Udev dadurch den Namen "em1" zuteilen, wobei das "em" für "embedded" steht; Netzwerkkarten folgen dem Muster "pci<slot>#<port>" (etwa pci2#1), wodurch die Ports einer Netzwerkkarte immer unter dem selben Namen ansprechbar sein sollten, solange diese oder eine als Ersatz eingebaute Karte im selben Steckplatz steckt. Die Unterfunktionen von partitionierbaren Netzwerkkarten (NPAR) und solchen mit für Virtualisierung interessanter SR-IOV-Unterstützung erhalten zusätzlich einen Unterstrich und einen Nummer angehängt. Vlan-Funktionen sind wie bisher durch einen Punkt abgetrennt, Aliase durch einen Doppelpunkt.
Bei Vergabe der Bezeichnungen greift Biosdevname auf die in der PCI Firmware Specification 3.1 spezifizierten Informationsfelder zurück; fehlen die, versucht es die Angaben per Smbios zu erhalten. Dadurch sollen die Nummern hinter dem "em" mit jenen übereinstimmt, die auf dem Gehäuse oder dem Mainboard aufgedruckt ist – das soll Netzwerk-Admins die Kabelverteilung gerade bei Servern mit vielen Netzwerkbuchsen erleichtern. Findet Biosdevname über die erwähnten Wege keine Informationen, nutzt das Programm die PCI IRQ Routing Table und vergibt Nummern nach der Position in der Geräte-Hierarchie. USB-Netzwerkschnittstellen handhabt Biosdevname nicht, daher bekommen sie weiterhin Bezeichnungen wie "eth0"
Kernel-Versionsstatus
Seit der Freigabe der zweiten Vorabversion von 2.6.38 gab es in der vergangenen Woche wie erwartet nur kleinere und vergleichbar wenig Änderungen im Hauptentwicklungszweig von Linux; 2.6.38-rc3 dürfte in Kürze erscheinen.
Kurz nach Veröffentlichung des letzten regulären Kernel-Log erschienen zudem die dort bereits angekündigten Kernel-Versionen 2.6.32.28 und 2.6.36.3. Sie sind zwei von sechs derzeit aktiv gewarteten Kernel-Serien, die für Endanwender gedachte Kernel auf Basis von Versionen pflegen, die aus dem von Torvalds betreuten Hauptentwicklungszweig hervorgegangen sind.
Eine dieser Serien ist der von Greg Kroah-Hartman betreute Stable-Kernel, der sich bei der Pflege neuerdings stärker auf die jeweils aktuellste Version konzentrierten möchte, die aus dem Hauptentwicklungszweigs hervorging – das ist derzeit der Anfang des Jahres freigegebene Kernel 2.6.37, daher dürfte Kroah-Hartman demnächst einen Kernel 2.6.37.1 freigeben. Die Pflege für die vorangegangen Version will er nach einer kurzen Übergangsphase einstellen; der Stable-Kernel 2.6.36.3 dürfte daher einer der letzten der 36er-Stable-Serie sein.
Longterm-Kernel, Kernel-Log-Staccato
Longterm-Kernel
Der Anfang Januar erschienene neue Kernel 2.6.32.28 hätte vor einigen Wochen auch noch die Bezeichnung "Stable-Kernel" erhalten; allerdings kennzeichnen diese und alle weiteren in diesem Absatz genannten Kernel-Serien seit Dezember das Wort "Longterm", um anzuzeigen, dass sie über einen längeren Zeitraum gepflegt werden. Die 32er-Serie ist eine von fünf solchen Serien und wird ebenfalls von Kroah-Hartman betreut. Er hat sich auch mehrere Jahre um die Pflege der 2.6.27er-Serie gekümmert, diesen Job aber kürzlich an Willy Tarreau übergeben, der bei der Pflege etwas langsamer vorgehen will. Tarreau pflegt bereits seit einigen Jahren die 2.4er-Serie, will mit diesem Longterm-Kernel aber auf absehbare Zeit aufhören. Recht neu im Geschäft mit der Langzeit-Pflege sind Andi Kleen und Paul Gortmaker, die seit Dezember Longterm-Kernel auf Basis von 2.6.34 respektive 2.6.35 betreuten, weil sie das im Rahmen ihrer Arbeit ohnehin machen – Hintergründe zur Motivation und den Plänen der beiden finden sich den Ankündigungs-Mails zu ihren Longterm-Serien (1, 2).
Neben diesen quasi-offiziellen Stable- und Longterm-Kerneln listet die Startseite von Kernel.org derzeit noch einige Stable-Kernel, obwohl diese gar nicht mehr betreut werden; einige von ihnen weisen daher möglicherweise bekannte Sicherheitslücken auf. Außerdem pflegen einige Kernel-Hacker noch weitere Kernel-Zweige – Stefan Bader von Canonical hat etwa kürzlich den Kernel "2.6.32.28+drm33.13" freigegeben, die dreizehnte Ausgabe eines auf 2.6.32.28 basierenden Kernels mit frischeren DRM-Treibern aus den Kerneln der 33er-Reihe. Baders Kernel-Zweig ist ein Nebenprodukt, das bei der Pflege des auf Linux 2.6.32 basierenden Kernels von Ubuntu 10.04 abfällt, der ebenfalls die DRM-Treiber aus 2.6.33 nutzt.
Kernel-Log-Staccato
X-Server und Co.
- AMD hat einen zu den im professionellen Markt angesiedelten FireGL-Karten passende Beta-Version eines Linux-Grafiktreiber freigegeben, die OpenGL 4.1 unterstützt.
- Nvidia gab kürzlich die Version 260.19.36 (x86-32, x86-64) seiner Linux-Grafiktreiber frei. Sie bringen einige kleinere Verbesserungen und beseitigen einen Fehler, der den X-Server 1.9 zum Absturz bringen kann. Nvidia hat zudem die Beta-Version 270.18 (x86-32, x86-64) veröffentlicht, die einige größere Änderungen mitbringt – unter anderem Unterstützung für den noch in Entwicklung befindlichen X-Server 1.10.
- Nur einige Stunden, nachdem das letzte reguläre Kernel-Log die vertrackte Situation bei Grafiktreibern für Intels Sandy-Bridge-Prozessoren beschrieben hat, erschien die Final-Version eines passenden X.org-Treibers; er ist Bestandteil des kurz darauf veröffentlichten "Intel 2010Q4 graphics package", das auf alle anderen Bausteine für diese Grafikkerne verweist.
- Zu Intels Treiberpaket gehört auch das als "Developer Release" bezeichnete Mesa 7.10, das auch Verbesserungen an den 3D-Treibern für GPUs anderer Hersteller enthält. Parallel erschien zudem die Version 7.9.1, welche einige Fehler der Version 7.9 korrigiert.
- Openchrome-Entwickler Xavier Bachelot hat bekannt gegeben, dass VIA Dokumentation zu den 2D- und 3D-Funktionen des Grafikkerns Chrome9-HD veröffentlicht hat, der im Chipsatz VX900 steckt.
- Intel-Entwickler Jesse Barnes liefert in einem Blog-Eintrag einige Tipps zum Debugging von Problemen bei der Bildschirmansteuerung. Einige Tage später erläuterte Barnes in "Intel display controllers" grob einige Arbeitsweisen von Intels Prozessoren und Chipsätzen mit Grafikkern.
- Der ebenfalls bei Intel an Grafiktreibern arbeitende Chris Wilson hat kürzlich einen Patch für den GLX-Code von Mesa zur Diskussion gestellt, durch den das Ergebnis einer GLX-Operation für spätere Wiederverwertung gespeichert wird; beim Spiel "World of Padman" stieg dadurch die Framerate von 28 auf 45 Bilder pro Sekunde, wenn es per indirektem Redering (beispielsweise via X-Forwarding im Netzwerk) läuft.
- Eine der Vortragsreihen aus den Mitte März stattfindenden Chemnitzer Linux-Tagen wird sich mit dem Kernel und Kernel-nahen Themen beschäftigen. In einem dieser Vorträge wird der Kernel-Log-Autor einen Überblick über die Verbesserungen geben, welche die jüngsten und die in Kürze anstehenden Kernel-Versionen enthalten.
Kernel-Umland ("Plumbing layer"), Userland-Treiber, Entwicklertools, ...
- Die kürzlich freigegebene Version 4.20 des von vielen Linux-Distributionen mitgelieferten Speichertestprogramms Memtest86+ unterstützt nun auch Intels Sandy-Bridge-Prozessoren und AMDs Fusion-CPUs ("E-Series").
- Der IBM-Developerworks-Artikel "Run ZFS on Linux" liefert einen groben Einblick in die Technik des Solaris-Dateisystems ZFS und zeigt, wie man das Dateisystem mit ZFS-Fuse unter Linux nutzt.
- Junio C Hamano hat Git 1.7.4 veröffentlicht und deren wesentlichste Neuerungen in der Freigabe-Mail zusammengefasst.
- Die Entwickler des Projekts Hplip (Hewlett-Packard's Linux Imaging and Printing Software) haben die Version 3.11.1 der gleichnamigen Treiber für Drucker und Multifunktionsgeräte von HP veröffentlicht. Die Release Notes geben einen detaillierten Überblick über die wichtigsten Neuerungen – etwa die neue Unterstützung für zahlreiche noch junge Laserjet-Drucker oder die verbesserten Funktionen zur Ausrichtung von Druckköpfen. Zudem beherrscht Hplip nun weitere bei Multifunktionsgeräten eingesetzte Fax- und Scan-Protokolle.
- Dan Williams erläutert in einem Blog-Eintrag einige Hintergründe zu Linux-Treibern für Wimax sowie zum Stand der Wimax-Unterstützung im vom ihm entwickelten NetworkManager.
- Stephen Hemminger hat die für den Kernel 2.6.37 und dessen Nachfolger gedachte Version 2.6.37 der das Programm "ip" enthaltenen Netzwerkwerkzeug-Sammlung iproute2 veröffentlicht. Zu den Neuerungen zählt die Unterstützung für Flow Matching mit Hilfe von Rxhash.
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)