Linux-Kernel 3.13: Testphase beginnt
Das jetzt in die Testphase eintretende Linux-Kernel 3.13 enthält ein neues Firewall-Framework und Änderungen, durch die flotte Datenträger mehr Geschwindigkeit erzielen sollen. Der Kernel unterstützt nun auch einige kürzlich eingeführte AMD-Grafikkkarten.
Der im Januar erwartete Linux-Kernel 3.13 wird AMDs seit Linux 3.11 unterstützte Stromspartechnik DPM bei vielen Radeon-Grafikchips standardmäßig nutzen (1, 2, 3, 4, 5). Das ist jetzt absehbar, denn Linus Torvalds hat die erste Vorabversion von Linux 3.13 veröffentlicht; 19 Tage nach der Veröffentlichung von Linux 3.12 geht damit die Hauptentwicklungsphase von 3.13 zu Ende. Größere Änderungen gibt es in der jetzt beginnenden Testphase nur noch in Ausnahmefällen; hin und wieder legen die Kernel-Entwickler aber Funktionen lahm, wenn sich größere Probleme zeigen, die sie nicht auf die Schnelle beheben können.
Wie erwartet haben die Kernel-Entwickler auch das Nftables-Framework in den Linux-Kernel aufgenommen. Es soll langfristig den protokollspezifischen und daher mühsam zu wartenden Netfilter-Code ersetzen, mit dem Linux-Firewalls bislang Pakete filtern. Der alte und über Iptables angesprochene Code bleibt aber vorerst im Kernel; zudem gibt es Userspace-Anwendungen, die Iptables-Filterregeln interpretieren und an Nftables übergeben.
Linux 3.13 enthält zudem grundlegende Unterstützung für den Grafikkern, der in Intels im nächsten Jahr erwarteten Broadwell-Prozessoren steckt. Der Treiber für Grafikkerne von AMD unterstützt bei 3.13 die kürzlich vorgestellten Grafikkerne der Hawaii-Generation und aktiviert HDMI-Audio bei vielen Radeon-Chips jetzt standardmäßig.
In den Kernel ist zudem Code eingeflossen, damit Prozesse auf NUMA-Systemen idealerweise Arbeitsspeicherbereiche verwenden, die der Prozessor, auf dem ein Prozess läuft, am schnellsten erreichen kann. Zum Block Layer stieß der "Multi-Queue Block IO Queueing Mechanism". Das soll das Design von Storage-Treiber erleichtern und PCIe-SSDs, NVMe-Hardware und anderen schnellen Datenträger mehr Geschwindigkeit entlocken.
Für einen Sekundenbruchteil war auch das Dynamic-Tracing-Framework Ktap ein Bestandteil im Staging-Bereich des Linux-Kernels, in dem qualitativ unzureichender Code liegt. Ktap flog aber sofort wieder raus, weil die Entwickler bereits im Oktober eine Überarbeitung des Codes vereinbart hatten, damit sich Ktap besser in die existierende Tracing- und Power-Management-Infrastruktur des Kernels einfügt. Die kurzzeitige Aufnahme einige Wochen später erfolgte lediglich, um ein Git-Rebase beim Staging-Zweig zu vermeiden. (thl)
