Kernel-Log – Was 3.4 bringt (1): Infrastruktur | heise online
heise PlusAbo
Anzeige

Kernel-Log – Was 3.4 bringt (1): Infrastruktur

Das x32-ABI will die Vorteile von x86-64-CPUs nutzbar machen, aber den Overhead von 64-Bit-Code vermeiden. Xen soll stromsparender laufen. Das neue Yama verhindert den Blick in den Speicher fremder Prozesse.

vorlesen Druckansicht 15 Kommentare lesen
Lesezeit: 27 Min.
c't Magazin
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Vergangenes Wochenende hat Linus Torvalds die vierte Vorabversion von Linux 3.4 veröffentlicht; bis zur Freigabe dieser Mitte oder Ende Mai erwarteten Kernel-Version dürften noch zwei bis vier weitere folgen.

Wie üblich haben die Kernel-Entwickler alle größeren Neuerungen dieser Version zu Beginn der Entwicklung aufgenommen. Das Kernel-Log kann daher bereits jetzt einen umfassenden Überblick über die wichtigsten Neuerungen von Linux 3.4 geben, denn es ist sehr selten, dass die Kernel-Entwickler in der jetzt laufenden Stabilisierungsphase noch größere Änderungen integrieren oder Neuerungen wieder entfernen.

Wie gewohnt geben wir eine Übersicht im Rahmen einer Artikelserie, die sich nacheinander verschiedenen Bereichen des Kernels annimmt. Den Anfang macht die folgende Beschreibung der wichtigsten Neuerungen rund um Architektur-Code und grundlegende Infrastruktur; die folgenden Artikel beschäftigen sich mit Grafiktreibern, Dateisystemen, Storage-Unterstützung und Treibern für andere Hardware.

Hybridbetrieb

Für x86-64/x64-Prozessoren übersetzte Kernel können Programmen ab Linux 3.4 ein x32 genanntes ABI (Application Binary Interface) bieten (u. a. 1). Dafür kompilierte Programme haben Zugriff auf die die 64-Bit-Register und -Datenpfade der 64-Bit-Prozessoren, arbeiten aber nur mit 32-Bit-Pointern – die reichen für viele typische Aufgabenstellungen aus und belegen weniger Arbeitsspeicher als 64-Bit-Pointer.

Grob gesprochen vermeiden für das x32-ABI kompilierte Programme so den Overhead, den ein voller 64-Bit-Betrieb mit sich bringt, nutzen aber dennoch einige der wichtigsten Vorteile von 64-Bit-x86-Prozessoren. Letzteres gelingt nicht, wenn man 32-Bit-x86-Programme (x86-32/ix86) auf x86-64-Distributionen ausführt, wie es Linux seit den ersten Tagen der 64-Bit-x86-Unterstützung beherrscht.

Vorangetrieben wurde das Ganze maßgeblich von Intel-Entwicklern. Das neue ABI ist offenbar vornehmlich für den Embedded- und Mobil-Markt gedacht: Mittelfristig dürften Smartphones, Tablets und Co. mit x86-Prozessoren häufiger 4 GByte Arbeitsspeicher oder mehr haben, den ein 32-Bit-Kernel nur mit Tricks ansprechen kann; die meisten Programme auf solchen Geräten dürften aber keine 4 GByte Speicher und damit keine 64-Bit-Pointer benötigen, sodass sich der höhere Speicherverbrauch eines vollwertigen 64-Bit-Betriebs nicht lohnt. Die in diesem Umfeld eingesetzten Prozessoren sind zudem eher schwächer, daher fallen die durch 32- statt 64-Bit-Pointer erzielbaren Vorteile stärker ins Gewicht. Bei typischen x86-Prozessoren für Notebooks, Desktops oder Server ist der Overhead eines vollwertigen 64-Bit-Betriebs eher gering, daher dürften die klassischen x86-64-Distributionen die beiliegende Software weiterhin als 64-Bit-Programme für das native x86-64-ABI mitliefern.

Weitere Hintergründe liefern die Homepage des x32-Projekts und ein LWN.net-Artikel zum neuen ABI.

Virtualisierung

Unter den Änderungen am Xen-Code für Linux 3.4 (u. a. 1, 2) ist eine, durch die der Kernel der Dom0 einige der vom BIOS gelieferten ACPI-Informationen zu den Takt- und Schlafzuständen des Prozessors an den Xen-Hypervisor senden kann, nachdem der Kernel diese interpretiert hat. Der Hypervisor kann sich mit diesen Informationen um das Anpassen des Prozessortakts kümmern (P-States) oder die CPU in Kurzzeitschlafzustände (C-States) versetzen. Das reduziert die Leistungsaufnahme, was die Akku-Laufzeit von Notebooks signifikant verlängern kann.

Durch die Kernel-Interpretation kommt der Xen-Hypervisor weiter ohne vollwertigen ACPI-Interpreter aus. Der Dom0-Kernel kann sich nicht selbst um die Taktanpassung oder das Schlafenlegen kümmern, da der Hypervisor die Kontrolle über das System hat und nur er einen Überblick über die Gesamtauslastung des Systems besitzt; eine laufende Abstimmung zwischen Dom0-Kernel und Hypervisor dürfte zu viel Zeit kosten. Xen erfordert einige solcher Tricks – bei KVM sind die unnötig, weil der zuerst gestartete Linux-Kernel selbst als Hypervisor arbeitet.

KVM kann mit 3.4 nun auch PCI-2.3-Geräte an Gäste weiterreichen, die sich auf dem Host eine Interrupt-Leitung mit anderen PCI-Geräten teilen. Zum SCSI-Subsystem stieß der Treiber Virtio-Scsi, der sich zusammen mit der gleichnamigen Unterstützung in Qemu zu einer Datenträgeremulation eignet, die mit recht wenig Overhead den Datenverkehr zwischen Host und Gast regelt. Der Treiber soll laut seinem Entwickler flexibler sein, besser skalieren und einfacher in der Handhabung sein als Virtio-Blk, das Ähnliches biete, dem aber Funktionen für bestimmte Einsatzgebiete fehlen würden.

Renovierungsarbeiten, Verschiedenes

Renovierungsarbeiten

Die vor ungefähr einem Jahr durch ein Machtwort von Torvalds angestoßenen Auf- und Umräumarbeiten im ARM-Code gehen mit 3.4 weiter (u. a. 1, 2, 3). Durch das neue Common CLK API (u. a. 1, 2, Dokumentation) bietet der Kernel nun Basis-Funktionen, auf die Plattform-spezifischer Code zur Kontrolle von Taktgebern zurückgreifen kann; das soll den für solchen Aufgaben zuständigen Code vereinfachen und speziell Dubletten im ARM-Architektur-Code reduzieren. Das sind auch Ziele von Rpmsg und Remoteproc (u. a. 1, 2, 3, 4, 5), auf die Plattform-spezifischer Code nun zur Kommunikation mit sekundären Prozessoren (DSPs, GPUs oder Service-CPUs) zurückgreifen kann, die sich auf vielen SOCs (Sytem on Chip) finden.

Linux 3.4 spricht erstmals den Samsung-SOC Exynos5250 an; bei Nvidias Tegra 3 unterstützt der Kernel nun auch SMP. Zudem enthält nun auch der ARM-Kernel einen Just-in-Time-Compiler zum Filtern von Netzwerk-Paketen.

  • Durch einige Änderungen am x86-Code soll der Kernel zusammen mit Udev nun die zum jeweiligen Prozessor passenden Treiber automatisch laden können, wenn diese als Modul übersetzt wurden; das gelingt unter anderem mit den Treibern, die für die CRC-Funktionen oder den Wechsel der Taktstufen zuständig sind (u. a. 1, 2, 3, 4, 5, 6).
  • Die Kernel-Entwickler nahmen erneut eine Reihe von Verbesserungen an der Tracing-Infrastruktur auf (u. a. 1, 2); darunter ein einfaches GTK2+-Programm zur Analyse der Daten, die "perf report" erfasst. Zudem lässt sich die Ftrace-Infrastruktur nun auch über das Werkzeug Perf nutzen (u. a. 1, 2).
  • Über neue Konfigurationsoptionen können Anwender oder Distributionen vorgeben, unter welchen Umgebungsbedingungen der Kernel ASPM (Active State Power Management) standardmäßig nutzen soll. Die PCIe-Stromspartechnik war ins Gerede gekommen, weil der Kernel sie eine Weile nicht aktiviert hat, wenn BIOS und Hardware inkonsistente Informationen zur Unterstützung der Technik lieferten; dieses Problem wurde Anfang Februar behoben.
  • Das neu aufgenommene Security-Modul Yama kann Prozessen verbieten, über den Funktionsaufruf Ptrace (Process Trace) den Speicher anderer Prozesse zu untersuchen; SELinux beherrscht seit Kurzem eine ähnliche Funktion.
  • Zu den Änderungen am Code für Power/PowerPC-Prozessoren (PPC) zählen die Integration einer Firmware Assisted Dump (fadump) genannten Crash-Dump-Funktion und das Entfernen der Unterstützung für die Legacy iSeries.

Kleine Perlen: Infrastruktur

Die kleinen Perlen: Infrastruktur

Die folgenden Links führen zu einigen kleineren, aber keineswegs unbedeutenden Änderungen:

ACPI, PCI & Co.

Crypto & Security

Memory Management (MM)

Power Management

Tracing

Virtualisation

Various

Kleine Perlen: Architektur

Die kleinen Perlen: Architektur-Code

x86

ARM

PPC

Various

Ein "C" im Bereich "[  ]" kennzeichnet Commits mit Änderungen an Kconfig-Dateien, welche die Konfigurationsoptionen samt der zugehörigen Hilfetexte enthalten. Mit "D" ausgezeichneten Patches verändern die dem Kernel beiliegende Dokumentation; Commits mit "N" legen neue Dateien an. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: Eine "1" kennzeichnet Patches, die inklusive Kommentar zwischen 10 und 20 KByte groß sind; Patches mit einer "9" sind 90 KByte oder größer. Änderungen ohne Zahl sind kleiner als 10 KByte.

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)

Beliebte Bestenlisten

Alle Angebote
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten