Linux erhält Realtime-Fähigkeiten vielleicht schon im Winter
Linux-Entwickler sollen vielleicht einen Blue-Screen-of-Death erhalten. Das ermöglichen Umbauten für die Echtzeitfähigkeiten von Linux.
- Thorsten Leemhuis
Schon das Ende Januar 2020 erwartete Linux 5.5 könnte die erste Kernel-Version werden, die von Haus aus Echtzeitanforderungen erfüllt. Dazu muss aber einiges rundlaufen, wie der renommierte Kernel-Entwickler Thomas Gleixner kürzlich auf der Linux Plumbers Conference in einer Realtime-Microkonferenz durchblicken ließ, daher kann es letztlich vielleicht doch noch etwas länger dauern.
Latenz-Problem mit Protokoll-Infrastruktur
Damit der offizielle Linux-Kernel alles für Echtzeitfähigkeiten bieten kann, müssen noch einige Änderungen vom Realtime-Zweig (RT-Tree) in die offiziellen, via Kernel.org vertriebenen Linux-Versionen umziehen. Viel des für "PREEMPT _RT" benötigten soll laut Gleixner schon in Linux 5.4 einfließen, das in der zweiten Novemberhälfte erscheinen dürfte. Dabei hat geholfen, dass Linus Torvalds in der Hauptentwicklungsphase von Linux 5.3 einen Patch aufgenommen hat, mit dem er signalisiert hatte, die Realtime-Unterstützung als Bauoption in den offiziellen Kernel integrieren zu wollen.
Größte Unsicherheit ist derzeit noch eine grundlegende Überarbeitung der Infrastruktur für printk, mit dem Kernel-Code jegliche Log-Meldungen absetzt, sammelt, formatiert und ausgibt. Mit dem bislang dafür zuständigen Code lassen sich moderne Echtzeitanforderungen nicht erfüllen, weil er das Ausführen anderer Aufgaben manchmal zu lange blockiert. Im RT-Zweig wird dieses Problem mit einem unsauberen Hack umgangen, der für den offiziellen Kernel nicht gut genug ist.
(Bild: Screenshot einer Präsentation (Link: siehe Text))
Sauberer Ansatz mit Notfall-Ausgabeweg
Schon seit Jahren diskutieren die Entwickler über verbesserte Lösungen, konnten aber nicht übereinkommen. Unter anderem, weil Linux-Vater Torvalds darauf drängte, dass die printk-Infrastruktur auf jeden Fall alle relevanten Log-Meldungen ausgeben muss, wenn eine Kernel-Panic auftritt – der Kernel also bewusst die Weiterarbeit einstellt, weil er erkennt, dass ein sicherer Weiterbetrieb nicht möglich ist. Log-Ausgaben sind dann besonders wichtig, denn ohne lassen sich kritische Fehler nur schwer eingrenzen.
Auf der am Mittwoch zu Ende gegangen Linux Plumbers Conference kamen die Entwickler inklusive Torvalds überein, auf eine grundlegende neue printk-Infrastruktur von John Ogness umzuschwenken. Die arbeitet im Normalfall mit einem Ring-Buffer, dessen Inhalte asynchron ausgegeben werden; das vermeidet lange Latenzen, wenn Kernel-Code normale Vorgänge protokolliert. Bei kritischen Aktionen wie einer Kernel Panic arbeitet die neue Infrastruktur aber ohne den Buffer, um Informationen zur Panic auf jeden Fall auszugeben.
Irgendeine-Farbe-Screen-Of-Death
In den Diskussionen war auch ein leitender Entwickler des Grafiktreibercodes von Linux anwesend. Der erklärte, mit der neuen Printk-Infrastruktur würde es endlich leicht, zuverlässig und gefahrenfrei möglich, eine Kernel-Panic auch auf dem Schirm auszugeben, wenn gerade grafische Bedienerflächen wie Gnome-Shell oder KDE Plasma laufen.
Mit anderen Worten: Linux könnte endlich ein Äquivalent zum von Windows bekannten Blue-Screen-of-Death bekommen. Ob und wann diese Idee umgesetzt wird, muss sich noch zeigen. Außerdem witzelten die Entwickler, wie so oft in solchen Fällen stehe dazu noch das gefürchtete "Bike Shedding" an: Man müsse sich noch auf eine Hintergrundfarbe entscheiden, die bei Anzeige der Kernel-Panic genutzt wird.
Feintuning braucht Zeit
In der Diskussion waren sich die Entwickler zwar einig, die neue Printk-Infrastruktur zu nutzen, forderten aber noch einige Detailanpassungen. Es muss sich zeigen, wie lange John Ogness und seine Mitstreiter für deren Umsetzung benötigen, um das Ganze dann nach weiteren öffentlichen Begutachtungen in Linux einzubringen. Daher kann es gut sein, dass das Ganze für 5.5 noch nicht fertig wird und erst einige Versionen später einzieht.
Wenn die Aufnahme dann sicher ist, können darauf angewiesene Änderungen der Realtime-Linux-Entwickler folgen, durch die sich dann die Option zum Bauen eines Realtime-Kernels endlich zeigen sollte. Die für die Option nötige Änderung steckt zwar schon in der Nacht auf Montag, den 16. September erwarteten Linux-Kernel 5.3, zeigt sich dort aber noch nicht, denn die Aufnahme sollte nur Signalwirkung haben.
Hintergründe in Folien und Videos
Details zur neuen Printk-Infrastruktur finden sich in Vortragsfolien, die John Ogness auf der Konferenz gezeigt hat. Eine Video-Aufzeichnung seines Vortrags soll in den nächsten Tagen folgen. Die Diskussionen wurden nicht aufgezeichnet.
Weitere Details zum Stand des Realtime-Linux und anderen dafür diskutierten Entwicklungen finden sich über die Linux-Plumbers-Webseite zur Realtime-Linux-Microkonferenz und einem Etherpad, in dem die Teilnehmer Notizen gesammelt haben. So auch zur Fragerunde zum Stand des Realtime-Patches für Linux. Dort kam unter anderem auf, dass einige bekannte Kernel-Funktionen nicht zur Verfügung stehen, wenn man einen Realtime-tauglichen Kernel baut; darunter auch die derzeit von immer mehr Stellen verwendete BPF Virtual Machine Runtime. In der Diskussion kamen aber Ideen auf, wie sich dieses Manko vielleicht beseitigen lassen könne.
Zum Realtime-Patch in Linux 5.3 siehe auch das von c't publizierte Kernel-Log zu dieser Version, das bereits jetzt alle wesentlichen Änderungen des in der Sonntagnacht erwarten Kernels beschreibt:
(thl)
