zurück zum Artikel

Die Neuerungen von Linux 4.4

| Thorsten Leemhuis

Der Linux-Kernel 4.4 bringt Grafiktreiber für den Raspi und die 3D-Beschleunigung unter KVM mit. Neue Ansätze im Block-Layer versprechen High-End-SSDs mehr Leistung zu entlocken. Verbesserungen im Netzwerk-Subsystem sollen die Geschwindigkeit steigern und dadurch DDoS-Attacken erschweren.

Linus Torvalds hat den Linux-Kernel 4.4 freigegeben. Bei dieser Version haben die Kernel-Entwickler einige Verbesserungen [1] an dem Treiber Virtio-Gpu vorgenommen, der mit Linux 4.2 [2] integriert wurde. Linux-Distributionen, die in einer virtuellen Maschine unter KVM laufen, sollen über die Änderungen in Zukunft die 3D-Beschleunigung des Wirtssystems nutzen können.

Die Verbesserungen sind Teil eines über mehrere Jahre als "Virgl 3D" entwickelten Ansatzes. OpenGL-Befehle, die Anwendungen in der VM absetzen, landen bei einem 3D-Treiber der Grafikbibliothek Mesa im Gast-Linux. Dieser gibt die OpenGL-Befehle über den bei 4.4 verbesserten Virtio-Gpu-Treiber an den von KVM verwendeten Systememulator Qemu weiter, der auf dem Wirt läuft. Qemu wiederum führt die OpenGL-Befehle mit dem 3D-Treiber des Wirts aus, der dabei auf die Hardware-Beschleunigung des Grafikprozessors zurückgreift. Das Verfahren erfordert daher neben Linux 4.4 auch Mesa 11.1 [3] im Gast; Letzteres ist kurz vor Weihnachten erschienen. Das gilt auch für Qemu 2.5 [4], das auf dem Wirt erforderlich ist.

Virtualisierungs-Software von VMware oder VirtualBox ermöglicht schon länger eine Nutzung der 3D-Beschleunigung in Linux-VMs. Die VMware-Produkte sind allerdings proprietär und VirtualBox erfordert 3D-Treiber im Gast, die man bei vielen Distributionen mühsam nachinstallieren muss. Anders als Virgl 3D funktioniert der 3D-Support dieser beiden Virtualisierungslösungen allerdings auch in VMs mit Windows. Das gilt auch für das nach wie vor unfertige KVMGT [5] von Intel, bei dem die Grafiktreiber im Gast direkt auf Funktionen der Intel-GPU zugreifen.

Linux bringt in Version 4.4 erstmals einen Grafiktreiber [7] für die GPUs der Broadcom-Prozessoren mit, die auf den verschiedenen Ausführungen des Raspberry Pi sitzen. Dieser Treiber arbeitet weitgehend autark. Das ist der entscheidende Unterschied zu den Open-Source-Treibern, die bislang auf dem Raspi zum Einsatz kommen: Diese Treiber können selbst wenig und reichen viele Aufgabenan einen Grafiktreiber in der proprietären Firmware weiter.

Der neue, von Broadcom selbst vorangetriebene Treiber ermöglicht bei 4.4 allerdings keine 3D-Beschleunigung. Diese sollen Erweiterungen nachrüsten, die zur Aufnahme in Linux 4.5 vorgesehen [8] sind. Mit dem so verbesserten Treiber kann dann eine aktualisierte Version des zu Mesa gehörenden OpenGL-Treiber VC4 die 3D-Beschleunigung unterstützen, ohne dass der Grafiktreiber der proprietären Firmware involviert ist. Auch bei Linux 4.5 wird es aber noch Funktionen geben, die die alten Treiber besser beherrschen.

Der Mdraid-Code kann Software-RAIDs der Level 4, 5 und 6 nun mit einem weiteren Datenträger koppeln, auf dem er ein Log führt, um RAID-Inkonsistenzen bei Systemabstürzen zu verhindern (u.a. 1 [10], 2 [11], 3 [12]). Das Schutzverfahren ähnelt dem von Journaling-Dateisystemen wie Ext4: Der Kernel schreibt jede Änderung zuerst in das Log, bevor es sie auf die am RAID beteiligten Datenträger schreibt. Fällt die Stromversorgung beim Schreiben auf die RAID-Datenträger aus, kann der Kernel beim nächsten Start die im Log hinterlegten Daten nutzen, um die Änderungen wie geplant durchzuführen. So kann der Kernel eine als "Write Hole" bekannte Gefahr vermeiden und die Integrität eines RAIDs innerhalb kurzer Zeit wieder herstellen, ohne das RAID von vorne bis hinten prüfen zu müssen, wie es bislang nach Abstürzen sinnvoll ist.

Das Log kann auch die Geschwindigkeit ein klein wenig steigern, da es Änderungen kurz puffert. Vorerst benötigt man noch eine Entwicklerversion des Tools Mdadm, um ein RAID mit Log-Datenträger einzurichten. Weitere Hintergründe erläutert ein Artikel des Mdadm-Entwicklers bei LWN.net [13]. Die Log-Funktion für Mdraid stammt von Facebook-Mitarbeitern, die bereits an Erweiterungen arbeiten, die das Log zu einem vollwertigen Writeback-Cache machen. Dabei puffert das Log länger und mehr, um die Geschwindigkeit noch weiter zu steigern.

Neu ist auch Kernel-seitige Unterstützung für ein LightNVM genanntes Framework, das für "Open-Channel SSDs" gedacht ist (u. a. 1 [15], 2 [16], 3 [17] 4 [18]). Mit diesem Begriff bezeichnen die LightNVM-Entwickler einige vornehmlich für Server gedachte SSDs, bei denen das Betriebssystem Arbeiten übernehmen kann, die normalerweise der Flash Translation Layer (FTL) oder das Bad Block Management der SSD-Firmware erledigen. Das soll die Geschwindigkeit steigern, denn das Delegieren ans Betriebssystem vermeidet nicht nur Overhead, sondern auch störende Wechselwirkungen zwischen SSD-Firmware und Betriebssystem. Derzeit gibt es aber nur eine Handvoll SSDs, die das beherrschen. Weitere Hintergründe liefert ein LWN.net-Artikel [19] und die Homepage des LightNVM-Projekts [20].

Geschwindigkeitssteigerungen bei High-End-SSDs für Server verspricht auch eine neue, noch experimentelle Infrastruktur für den Block-Layer. Bei ihr nutzt der Kernel Polling, wenn er große Datenmengen mit besonders schnellen Datenträgern austauscht (u.a. 1 [22], 2 [23], 3 [24], 4 [25]). Das soll Latenzen senken und den Durchsatz steigern: Bei der Verarbeitung riesiger Datenmengen macht ein regelmäßiges Abrufen neuer Daten beim Controller weniger Arbeit als die Abarbeitung einer Vielzahl von Interrupts, die sonst entstehen. Dieser bei LWN.net näher erläuterte Ansatz [26] ist nicht neu, denn das Netzwerksubsystem und viele Netzwerk-Treiber beherrschen diesen Trick schon länger.

Linux 4.4 kann TCP-Handshakes schneller verarbeiten. Das reduziert Latenzen und erschwert zugleich DDoS-Attacken, schließlich kann der Kernel nun mehr Anfragen abarbeiten, bevor die Last so groß wird, dass er ins Straucheln gerät. Die bessere Performance ist unter anderem einigen Optimierungen der Locking-Mechanismen im TCP-Code zu verdanken (u. a. 1 [28]). Bei Tests durch den zuständigen Entwickler steigerten diese Änderungen die Zahl der per SYN/ACK hergestellten TCP-Verbindungen um das Zwei- bis Dreifache [29]. Der Entwickler hat darüber hinaus noch einige Umbauten an Codepfaden für das SO_REUSEPORT-Flag vorgenommen (u. a. 1 [30]), über das mehrere Anwendungen auf einem Port lauschen können; das konnte die Zahl der TCP-Handshakes noch mal nahezu verdoppeln [31].

[Update, 14.01.16, 09:15] Auf Nachfrage stellte der zuständige Entwickler klar, dass er keine zwei- bis dreifache Steigerung gemeint hat, wie sie der Kernel-Log-Autor fälschlicherweise unterstellt hatte [32]; gemeint gewesen sei vielmehr eine Steigerung um mehrere Größenordnungen. Die bezog sich aber nicht auf den Zustand direkt vor den Änderungen, sondern auf den Stand von zwei Jahren zuvor. Damals hat der Entwickler auf seinem Testsystem nur ungefähr zwanzigtausend TCP-Verbindungen per SYN/ACK hergestellten können. Zusammen mit den SO_REUSEPORT-Änderungen sollen es laut dem Entwickler nun rund sechs Millionen sein – also rund dreihundert Mal mehr als damals. [/Update]

Der neue Package-Loss-Algorithmus RACK (Recently ACK) [34] verspricht die Geschwindigkeit von TCP-Verbindungen zu steigern, bei denen häufiger Netzwerkpakete verloren gehen. Dazu versucht RACK etwaige Paketverluste anhand der Übertragungszeiten anderer Pakete zu erkennen, und nicht anhand der Reihenfolge, in der sie eintreffen, wie es bisherige Algorithmen meist tun. RACK ist vorerst experimentell und stammt von Google. Das Unternehmen setzt den Algorithmus offenbar schon eine Weile ein und hat ihn bei der IETF zur Standardisierung eingereicht [35].

Der bei Linux 4.3 [37] in den Grafiktreiber Amdgpu integrierte Scheduler ist jetzt standardmäßig aktiv [38]. Durch ihn kann der Treiber die von verschiedenen Userspace-Treibern und -Prozessen abgesetzten Befehlsketten eigenständig auf die Recheneinheiten des Grafikprozessors verteilen, um diese möglichst effizient zu nutzen und so die Performance zu verbessern. Der für die neueste Generation von Radeon-Grafikprozessoren zuständige Treiber Amdgpu spricht nun auch [39] die GPU von Stoney-Prozessoren an, die AMD in einigen Monaten auf den Markt bringen will.

Der Treiber für Intels moderne Grafikprozessoren unterstützt jetzt den Scheduler, der in Prozessoren der Generationen Skylake und Broxton sitzt. Ähnlich wie der GPU-Scheduler von AMD kann auch er Kommandos umsortieren, um Effizienz und Performance zu steigern. Vorerst ist diese "GuC-based command submission" des Intel-Treiber aber standardmäßig inaktiv. Sie erfordert zudem eine GuC genannte Firmware; diese ist über eine Intel-Webseite erhältlich [41], steckt seit einigen Wochen aber auch in der Firmware-Sammlung linux-firmware [42], die Linux-Distributionen typischerweise einrichten.

Der Intel-Grafiktreiber erhielt zudem allerlei Korrekturen an der Unterstützung für den Grafikprozessor in Prozessoren der Skylake-Generation, zu denen unter anderem die Core-i-6000er-CPUs gehören. Intels Entwickler sind indes abermals gescheitert, das Bildschirmflackern beim Systemstart zu reduzieren, um so den Boot-Prozess eleganter zu machen. Dazu sollte der Treiber in bestimmten Fällen auf das Setzen des Bildschirmmodus beim Start verzichten [43], denn das ist mit einer kurzen Bildstörung verbunden. Wie bei ähnlichen Anläufen zuvor zeigten sich aber auch diesmal wieder Probleme, daher wurde die Änderung abermals revidiert [44].

Details zu diesen und weitere Änderungen am i915-Treiber nennt dessen Betreuer in einem Blog-Eintrag [45].

Der Nouveau-Treiber kann jetzt Grafikkarten auf denen GDDR3-Speicher sowie eine Nvidia-GPU der Baureihen G94 bis G200 sitzt, in ihre stromsparendsten oder schnellsten Betriebmodi schalten [47]; in diese Klasse fallen unter anderem die GeForce-Grafikkarten 9400 GT, 9600 GT sowie die GeForce-GTX-Karten 260, 275, 280, 285 und 295, die schon über fünf Jahre alt sind. Diese Unterstützung zum Reclocking soll die Performance deutlich verbessern: Bislang liefen Speicher und Grafikprozessor dieser Grafikkarten mit den beim Booten von der Firmware eingestellten Standard-Taktfrequenzen, bei der die Grafik-Hardware ihr Leistungspotenzial bei weitem nicht ausspielen kann. Eine andere Änderung [48] soll die Reclocking-Unterstützung für Karten der Kepler-Generation verbessern, zu der unter anderem die GeForce-GTX-Modelle 660 Ti, 670, 680, 690, 760, 760 Ti und 770 gehören.

Zu den neu zum Kernel gestoßenen Treibern gehört einer [50], der verschiedene USB-WLAN-Chips von Realtek anspricht – darunter die Bausteine RTL8723AU, RTL8188CU, RTL8188RU, RTL8191CU und RTL8192CU. Für diese Chips brachte der Kernel bislang die Treiber Rtl8723au, Rtl8192u und Rtlwifi mit, die im Staging-Bereich stecken, weil sie größere Qualitätsmängel aufweisen. Der neue, von Grund auf neu entwickelte Treiber soll besser werden, ist aber noch unfertig und lässt einige Funktionen der Staging-Treiber missen.

Der Kernel unterstützt einige per Firewire angesprochene Sound-Chips jetzt besser (u. a. 1 [51], 2 [52], 3 [53], 4 [54], 5 [55]). Neu dabei ist auch ein Audio-Treiber für Skylake-Notebooks [56], bei denen der Audio-Chips per I2S angebunden ist; eine solche Konfiguration ist vornehmlich in einigen teuren Ultrabooks zu finden.

Der Wacom-Treiber steuert jetzt vier weitere Grafiktabletts der Intuos-Serie [57] sowie das Cintiq Companion 2 [58] an. Ein neuer Treiber [59] soll die ungewöhnliche Handhabung der Escape-Taste bei Lenovos Yoga-3-Modellen mit 11-, 13- und 14-Zoll-Display verbessern, die offenbar vielen Linux-Anwender Schwierigkeiten bereitet.

Facebook-Entwickler haben die Prozessorlast beim Einsatz der Btrfs-Mount-Option ssd_spread reduziert (u. a. 1 [61], 2 [62], 3 [63]). Zuvor hatten sie festgestellt [64], dass die darüber aktivierte Datenverteilungsmethode die Performance bei ihren Hardware-RAIDs der Level 5 und 6 erheblich verbessert.

Der NFS-Clientcode unterstützt jetzt die NFS-4.2-Operation "CLONE", mit der sich Dateien oder Dateibereiche innerhalb eines NFS-Shares serverseitig kopieren lassen – also ohne die Dateinhalte von Server an den Client und wieder zurück übertragen zu müssen (1 [66], 2 [67]). Die dazu verwendeten Funktionsaufruf sind jenen nachempfunden, die das Btrfs-Dateisystem bietet; auf sie greift etwa cp --reflink zurück, um Dateien innerhalb eines Btrfs-Volumes zu kopieren, ohne deren Inhalte zu duplizieren.

Der Code zum Mounten von Dateisystemen über Loop-Devices beherrscht jetzt Direct I/O (DIO) und Asynchronous I/O (AIO) [69], was die Geschwindigkeit steigern und Overhead reduzieren soll.

Die bei Linux 4.1 [70] integrierte Unterstützung zum Clustern eines MD-RAID 1 soll jetzt nahezu komplett sein [71]; über diese noch experimentelle Funktion soll sich ein RAID 1 auf einem zweiten Rechner spiegeln lassen, damit die auf dem RAID enthaltenen Daten auch erreichbar bleiben, wenn einer der beiden Rechner ausfällt.

Block-Layer [72] sowie SCSI [73]-, NVMe [74]- und Device-Mapper [75]-Code beherrschen jetzt Persistent Reservations (PRs) [76]. Diese in SCSI-3 und SCSI-4 definierten Technik wird vornehmlich in High-Availability-Clustern eingesetzt, um einzelnen Clients exklusiven Zugriff auf bestimmte Datenträgerbereiche (I/O Fencing) und zugleich Ausfallsicherheit mit Failover und Retakeover zu bieten.

Der Kernel und sein eigener Hypervisor KVM unterstützen nun eine "VT-d posted interrupts" oder "Hardware-Interrupt-Bypass" genannten Funktion, bei der das System einen Interrupt direkt an eine vorher festgelegte virtuelle Maschine sendet (u. a. 1 [78], 2 [79], 3 [80], 4 [81], 5 [82], 4 [83]). Das vermeidet Overhead und steigert die Geschwindigkeit, da seltener vom Gast in den Host und zurück gewechselt werden muss.

Auch unprivilegierte Anwendungen können nun [85] vom eBPF (extended Berkeley Packet Filter) ausgeführte Programme in den Kernel laden, um damit Datenströme zu verarbeiten, die durch den Kernel fließen. Dadurch kann beispielsweise ein nicht von Root ausgeführtes Tcpdump in Zukunft einen eBPF-Filter beim Kernel hinterlegen, damit der nur die Netzwerkpakete an den Sniffer weitergibt, die der Nutzer untersuchen will. Von unprivilegierten Anwendern stammende eBPF-Programme unterliegen allerdings einigen Einschränkungen, damit Angreifer den eBPF-Interpreter nicht missbrauchen; Details hierzu erläutert LWN.net [86].

Anwendungen können eBPF-Programme und von ihnen verwendete Datenstrukturen nun persistent im Kernel hinterlegen, damit diese auch nach Beenden der Anwendungen verfügbar bleiben und von anderen Programmen wieder aufgegriffen werden können (siehe u. a. 1 [88], 2 [89] sowie LWN.net [90]). Das zur IP-Werkzeugsammlung Iproute2 gehörende Programm tc (Traffic Control) will das nutzen, um eBPF-Daten zwischen mehreren Classifiern und Actions zu teilen. Dadurch könnte man mit dem Programm beispielsweise einen Load-Balancer mit eBPF Classifier bauen, eine simple Firewall programmieren oder einen einfachen Connection-Tracker realisieren, was vor allem beim Einsatz in größeren Rechenzentren interessant sein kann. Im Entwicklerzweig von Iproute2 enthaltene Code greift auf die neue Kernel-Funktion bereits zurück (1 [91], 2 [92], 3 [93], 4 [94], 5 [95]); diese Änderungen sollen Bestandteil von Iproute2 4.4 werden, das im Fahrwasser von Linux 4.4 erscheinen soll.

Unabhängig von den anderen eBPF-Änderungen haben die Entwickler das Performance-Analyse-Werkzeug Perf erweitert, damit es eBPF-Programme automatisch bauen, prüfen und in den Kernel laden kann (u. a. 1 [97], 2 [98], 3 [99], 4 [100], 5 [101]). Über solche Programme kann der Kernel irrelevante Informationen zu Vorgängen im System frühzeitig ausfiltern, was Overhead und Störeinfluss der Analyse reduziert.

Eine Reihe von Änderungen am Speichermanagement-Code soll dessen Performance und Robustheit verbessern. Eine von ihnen entfernt etwa eine Cache-Funktion, die sich als störend statt hilfreich entpuppte. In einem Test des Entwicklers reduzierte dieser Schritt eine Latenz in einem Lasttest [103] von 24 auf 12 Sekunden; weitere Details erläutert LWN.net [104].

Zur grafischen Konfiguration eigener Kernel über make xconfig benötigt man jetzt die Entwicklerdateien von Qt4 oder Qt5, denn die Kernel-Hacker haben die auf Qt3 aufbauende Variante des Konfigurationswerkzeugs entfernt [106] und eine Qt5-Variante eingepflegt (u. a. 1 [107], 2 [108]).

Anders als in der jüngsten Vergangenheit wurde diesmal vorab angekündigt, dass Linux 4.4 ein "Longterm-Kernel" wird. Die Kernel.org-Entwicker wollen ihn daher nicht nur knapp drei Monate, sondern bis mindestens Januar 2018 mit Fehlerkorrekturen und kleineren Verbesserungen versorgen. In Zukunft soll wohl immer die jeweils im Januar aktuelle Linux-Version zu einem Longterm-Kernel werden, was Firmen die Planung erleichtern soll. Weitere Hintergründe liefern die heise open-Meldung zur Langzeitpflege beim Linux-Kernel 4.4 [110] und ein Bericht beim LWN.net [111].

Mit der Freigabe von Linux 4.4 [113] hat zugleich die Phase begonnen, in der Linus Torvalds das Gros der Änderungen für Linux 4.5 aufnimmt; dieses "Merge Window" beendet er typischerweise nach zwei Wochen, wenn er die erste Vorabversion der nächsten Kernel-Version veröffentlicht.

Unter den zur Aufnahme vorgesehenen Änderungen sind unter anderem Erweiterungen für den Grafiktreiber Amdgpu, die Unterstützung für PowerPlay nachrüsten. Der Treiber soll dadurch die sparsamsten und schnellsten Betriebsmodi von Grafikkarten aktivieren können, auf denen Grafikprozessoren der Volcanic-Island-Generation sitzen. Radeon-Grafikkarten wie die R9 380X oder die Modelle der R9-Fury-Reihe sollten dadurch deutlich mehr 3D-Performance bieten: Bislang liefen sie mit den beim Booten eingestellten Standard-Taktfrequenzen und konnten ihr Leistungspotenzial so bei weitem nicht ausspielen.

Sofern Torvalds und seine Mitstreiter im gewohnten Tempo arbeiten, sollte der Linux-Kernel 4.5 in der ersten Märzhälfte erscheinen.

Die neue Linux-Version steht über Kernel.org zum Download [114] bereit. Hinweise zur Einrichtung eines eigenen Kernels finden Sie im heise open-Artikel "Linux-Kernel maßgeschneidert [115]", der eine weitgehend automatische Kernel-Konfiguration mit Hilfe von make localmodconfig beschreibt.

Fedora und Rolling-Release-Distributionen wie Arch, Gentoo und OpenSuse Tumbleweed sollten die neue Kernel-Version in den nächsten Wochen als reguläres Update erhalten. Solche Kernel-Updates gibt es bei Ubuntu und vielen anderen Distributionen nicht; der für Ubuntu 16.04 vorgesehene Kernel soll allerdings auf Linux 4.4 aufbauen.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne Doku)²
Entwick-
lungs-
zeitraum
Anzahl
Commits³
Diffstat⁴
Linux 3.18 [117] 47986 18994096
(17586160)
63 Tage 12361 9303 files changed,
 485509 insertions(+),
 355800 deletions(-)
Linux 3.19 [118] 48440 19130604
(17692109)
63 Tage 13652 10739 files changed,
483355 insertions(+),
346843 deletions(-)
Linux 4.0 [119] 48957
19312370
(17847304)
63 Tage
11306
9489 files changed,
 508686insertions(+),
 326917 deletions(-)
Linux 4.1 [120] 49457 19512485
(18004436)
70 Tage 12965 10094 files changed,
 453375 insertions(+),
 253259 deletions(-)
Linux 4.2 [121] 50795 20311717
(18755735)
70 Tage 14750 10926 files changed,
 1079245 insertions(+),
 280008 deletions(-)
Linux 4.3 [122] 51570 20621444
(19031051)
63 Tage 13282 10385 files changed,
 642760 insertions(+),
 333026 deletions(-)
Linux 4.4 52221 20862115
(19243827)
70 Tage 14082 10604 files changed,
 713754 insertions(+),
 470774 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l
² find . -type f -not -regex '\./\.git.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git.*' | xargs cat | wc -l))"
³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l
⁴ git diff --shortstat vx.(y-1)..vx.(y)

(thl [123]) (thl [124])


URL dieses Artikels:
https://www.heise.de/-3053832

Links in diesem Artikel:
[1] https://git.kernel.org/torvalds/c/62fb7a5e10962ac6ae2a2d2dbd3aedcb2a3e3257
[2] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2789351.html
[3] https://www.heise.de/news/Aktualisierte-3D-Treibersammlung-fuer-Linux-ermoeglicht-3D-in-KVM-VMs-3044636.html
[4] https://www.heise.de/news/Virtualisierungs-Software-Qemu-2-5-3D-in-Linux-VMs-und-bessere-Live-Migration-3045690.html
[5] https://01.org/kvm/blogs/albcamus/2014/kvmgt-first-release
[6] 
[7] https://git.kernel.org/torvalds/c/c8b75bca92cbf064b9fa125fc74a85994452e935
[8] http://anholt.livejournal.com/45752.html
[9] 
[10] https://git.kernel.org/torvalds/c/f6bed0ef0a808164f51197de062e0450ce6c1f96
[11] https://git.kernel.org/torvalds/c/0576b1c618ef220051a8555f2aa7dd316e88f330
[12] https://git.kernel.org/torvalds/c/355810d12a8974ff1f3a7336149b65d4bda84634
[13] http://lwn.net/Articles/665299/
[14] 
[15] https://git.kernel.org/torvalds/c/effa04cc5a31b3f12cda6025ab93460f1f0e454e
[16] https://git.kernel.org/torvalds/c/cd9e9808d18fe7107c306f6e71c8be7230ee42b4
[17] https://git.kernel.org/torvalds/c/ca0640850e43f5f80c6029e2895b119b705f23bd
[18] https://git.kernel.org/torvalds/c/48add0f5a6f46919dd307575aad6ea3de7c9cb2a
[19] http://lwn.net/Articles/641247/
[20] http://lightnvm.io/
[21] 
[22] https://git.kernel.org/torvalds/c/3419b45039c6b799c974a8019361c045e7ca232c
[23] https://git.kernel.org/torvalds/c/05229beeddf7e75e2e616ddaad4b70e7fca9528d
[24] https://git.kernel.org/torvalds/c/15c4f638f3d41bae52105ca4c0c8760afbcbeaab
[25] https://git.kernel.org/torvalds/c/a0fa9647a54e81883abd57c5c865d1747f68a577
[26] http://lwn.net/Articles/663879/
[27] 
[28] https://git.kernel.org/torvalds/c/e994b2f0fb9229aeff5eea9541320bd7b2ca8714
[29] http://thread.gmane.org/gmane.linux.network/380654
[30] https://git.kernel.org/torvalds/c/70da268b569d32a9fddeea85dc18043de9d89f89
[31] http://thread.gmane.org/gmane.linux.network/381777
[32] http://www.heise.de/forum/Open-Source/Kommentare/Die-Neuerungen-von-Linux-4-4/Womoeglich-eine-Fehler-an-der-Quelle-was-Re-Fehler-im-Artikel/posting-24107611/show/
[33] 
[34] https://git.kernel.org/torvalds/c/e994b2f0fb9229aeff5eea9541320bd7b2ca8714
[35] https://tools.ietf.org/html/draft-cheng-tcpm-rack-00
[36] 
[37] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2789351.html
[38] https://git.kernel.org/torvalds/c/36b4ba07d673032d71045bc149930b0f176e6292
[39] https://git.kernel.org/torvalds/c/e3c7656c22697eeef46ce043e23417241844ab1c
[40] 
[41] https://01.org/linuxgraphics/intel-linux-graphics-firmwares
[42] http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
[43] https://git.kernel.org/torvalds/c/6764e9f8724f1231b4deac53b9a82286ac0830e7
[44] https://git.kernel.org/torvalds/c/7383123647566a813692bb37a1389c767ed89158
[45] http://blog.ffwll.ch/2015/12/neat-drmi915-stuff-for-44.html
[46] 
[47] https://git.kernel.org/torvalds/c/0d42743dfa908a2ca4e349f883361906ebb4db95
[48] https://git.kernel.org/torvalds/c/78eaf335e4c8224e74e5d512f20ec48109db9dac
[49] 
[50] https://git.kernel.org/torvalds/c/26f1fad29ad973b0fb26a9ca3dcb2a73dde781aa
[51] https://git.kernel.org/torvalds/c/0280d1a099da1d211e76ec47cc0944c993a36316
[52] https://git.kernel.org/torvalds/c/9edf723fd85822c7b7d8ef4f41a74c5a33eeca0c
[53] https://git.kernel.org/torvalds/c/3a2a17974eef10766ffbd7d3e9f5191fbb3c9f33
[54] https://git.kernel.org/torvalds/c/c0949b278515da948597b4a1a2726f42591ef385
[55] https://git.kernel.org/torvalds/c/35efa5c489de63a9bdbb7ea4e66dcfadcca951b4
[56] https://git.kernel.org/torvalds/c/624729fd51871bfbddb647764f180126789a29ee
[57] https://git.kernel.org/torvalds/c/eda01dab53b1126a20da98b5d691f3e55d79f21d
[58] https://git.kernel.org/torvalds/c/f7acb55cf1b414f8f515697f2a7bb324ba009062
[59] https://git.kernel.org/torvalds/c/74caab996c68393c0a985dccfd0ee6b33fb016e6
[60] 
[61] https://git.kernel.org/torvalds/c/0b670dc44c91bd1e5fac15b5ac4c98c8bd255ca2
[62] https://git.kernel.org/torvalds/c/36af4e0737f6aa494e43497a5a34588a1d5cb12f
[63] https://git.kernel.org/torvalds/c/a5e681d9bd641c4f0677e87d3a0c92a8f4f16293
[64] https://git.kernel.org/torvalds/c/27eb427bdc0960ad64b72da03e3596c801e7a9e9
[65] 
[66] https://git.kernel.org/torvalds/c/bea51b30b281039f0f43fb4f42028ddf33fb601f
[67] https://git.kernel.org/torvalds/c/a340abcf4173461f688292a6879b4d5bc781c2b1
[68] 
[69] https://git.kernel.org/torvalds/c/bc07c10a3603a5ab3ef01ba42b3d41f9ac63d1b6
[70] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2715850.html?artikelseite=2
[71] https://git.kernel.org/torvalds/c/ac322de6bf5416cb145b58599297b8be73cd86ac
[72] https://git.kernel.org/torvalds/c/bbd3e064362e5057cc4799ba2e4d68c7593e490b
[73] https://git.kernel.org/torvalds/c/924d55b06347d813b38c51e75ce1a6666c113933
[74] https://git.kernel.org/torvalds/c/1d277a637a711af44574229c544c44126ad5bf32
[75] https://git.kernel.org/torvalds/c/71cdb6978a80f9f6c51bef0622388c1414c2fe32
[76] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/block/pr.txt
[77] 
[78] https://git.kernel.org/torvalds/c/1a02b27035f82091d51ecafcb9ccaac1f31d4eb2
[79] https://git.kernel.org/torvalds/c/efc644048ecde54f016011fe10110addd0de348f
[80] https://git.kernel.org/torvalds/c/87276880065246ce49ec571130d3d1e4a22e5604
[81] https://git.kernel.org/torvalds/c/f73f8173126ba68eb1c42bd9a234a51d78576ca6
[82] https://git.kernel.org/torvalds/c/bf9f6ac8d74969690df1485b33b7c238ca9f2269
[83] https://git.kernel.org/torvalds/c/b7d2063177a584cb1afb06fc0ed6c48b576f3e75
[84] 
[85] https://git.kernel.org/torvalds/c/1be7f75d1668d6296b80bf35dcf6762393530afc
[86] http://lwn.net/Articles/660331/
[87] 
[88] https://git.kernel.org/torvalds/c/b2197755b2633e164a439682fb05a9b5ea48f706
[89] https://git.kernel.org/torvalds/c/42984d7c1e563bf92e6ca7a0fd89f8e933f2162e
[90] http://lwn.net/Articles/664688/
[91] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=32e93fb7f66d55d597b52ec3b10fd44a47784114
[92] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=910b543dcce52290ce723758e1d9bb436188a26b
[93] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=9e607f2e722604a57a2c1ec9a174fcc505d9c451
[94] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=f6793eec4600a9f9428026ed75c50a44eeb3c83f
[95] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=91d88eeb10cd4f51e3b5c675c7aee4ae1e41ff16
[96] 
[97] https://git.kernel.org/torvalds/c/1f45b1d49073541947193bd7dac9e904142576aa
[98] https://git.kernel.org/torvalds/c/69d262a93a25cf475012ea2e00aeb29f4932c028
[99] https://git.kernel.org/torvalds/c/1f45b1d49073541947193bd7dac9e904142576aa
[100] https://git.kernel.org/torvalds/c/aa3abf30bb28addcf593578d37447d42e3f65fc3
[101] https://git.kernel.org/torvalds/c/d509db0473e40134286271b1d1adadccf42ac467
[102] 
[103] https://git.kernel.org/torvalds/c/f77cf4e4cc9d40310a7224a1a67c733aeec78836
[104] https://lwn.net/Articles/658081/
[105] 
[106] https://git.kernel.org/torvalds/c/8328447af88eaab1db29852cb3e4a71cda5bd887
[107] https://git.kernel.org/torvalds/c/b3c48f964cda9311030416d1ee17bd5bdc4729f2
[108] https://git.kernel.org/torvalds/c/9bfda0ab03877855d9018712a046de0c9e147d34
[109] 
[110] https://www.heise.de/news/Der-Linux-Kernel-4-4-bekommt-Langzeitpflege-2863275.html
[111] https://lwn.net/Articles/662966/
[112] 
[113] http://article.gmane.org/gmane.linux.kernel/2123077
[114] https://kernel.org
[115] https://www.heise.de/tests/Linux-Kernel-massgeschneidert-1402386.html
[116] 
[117] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2482186.html
[118] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2541595.html
[119] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2600242.html
[120] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2715850.html
[121] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2789351.html
[122] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-2860564.html
[123] mailto:thl%40ct.de
[124] mailto:thl@ct.de