In der Mailingliste der Linux-Kernel-Entwickler wurden Patches veröffentlicht, die die Architektur „Wasm“ für den Linux-Kernel implementieren. Dies ermöglicht die Kompilierung des Kernels in Zwischen-Code von WebAssembly, der direkt im Webbrowser ausgeführt werden kann, ohne Emulatoren zu verwenden. Zudem wurde die Möglichkeit geschaffen, ausführbare Dateien im Format „.wasm“ im Linux-Kernel zu starten, und ein Treiber „web console“ wurde vorbereitet, um die Arbeit mit der Konsole im Browser zu simulieren. Außerdem steht ein Werkzeugset zur Verfügung, das die Erstellung von Systemumgebungen vereinfacht, die im Browser ausgeführt werden können.
Als Beispiel wurde eine Umgebung auf Basis der in WebAssembly kompilierten Utils von BusyBox und der Systembibliothek musl geschaffen. Für die Arbeit mit einer solchen Umgebung wird Xterm.js als Terminalemulator verwendet. Separat wurde eine Demowebsite gestartet, die es ermöglicht, die Arbeit des Ports zu bewerten, ohne selbst zu kompilieren. Es wird vollständige Unterstützung für Browser auf Chromium-Basis und teilweise Unterstützung für Firefox angekündigt, in dem die Debugging-Möglichkeiten eingeschränkt sind. Auf modernen Computern dauert das Laden des Wasm-Kernels im Browser weniger als eine Sekunde.
Das Projekt entwickelt sich bereits seit etwa zwei Jahren und ermöglicht es derzeit, den Kernel in Browsern zu laden und typische Programme auszuführen. Die Arbeit ist noch nicht abgeschlossen, und der Port hat einige Probleme und Einschränkungen. So wird beispielsweise die Unterstützung für die Aufrufe vfork und longjmp noch nicht bereitgestellt (für BusyBox wurden Patches angewendet, um ohne sie zu arbeiten), die Möglichkeit, Aufgaben zu unterbrechen, fehlt, und der MMU ist nicht verfügbar (Kernel und Prozesse arbeiten im selben Adressraum). Es ist nicht möglich, bereits geladenen Code zu ändern, und die Konsole friert nach etwa 5 Minuten aufgrund von Timer-Problemen ein. Es wird darauf hingewiesen, dass die vorhandenen Einschränkungen überwindbar sind, aber für einige von ihnen die Implementierung zusätzlicher Erweiterungen für WebAssembly in Browsern erforderlich ist. Solche Erweiterungen wurden für MMU und die Unterbrechung von Threads vorgeschlagen.
Die Unmöglichkeit, die Ausführung von Threads in WebAssembly anzuhalten, steht im Widerspruch zur Arbeitsweise des Task-Schedulers im Kernel. Allerdings konnte Multitasking über einen Umweg realisiert werden, indem jeder Thread/Aufgabe an seine eigene virtuelle CPU gebunden wird, die in einem separaten Web Worker verarbeitet wird. Auf diese Weise wurde es möglich, die parallele Ausführung von Prozessen durch die Browser-Engine und den Kern des Host-Betriebssystems zu erreichen, ohne auf preemptives Multitasking und den Task-Switching im im Browser laufenden Kernel zurückzugreifen. Unterbrechungen und Signale funktionieren in diesem Schema nicht vollständig, und um Timer-Interrupts und IPI (Inter-Processor Interrupt) zu liefern, wird eine separate virtuelle CPU eingesetzt.
Der Anwendungsbereich des Projekts geht über das bloße Starten von Linux-Umgebungen in Browsern hinaus. Zum Beispiel kann der Port zur Erstellung plattformübergreifender WebAssembly-Programme verwendet werden, die linux-spezifische Systemaufrufe nutzen. Die Implementierung solcher Systemaufrufe kann separat in WebAssembly umgewandelt und an die Anwendung angehängt werden, was die Nutzung unabhängig vom Systems Kernel ermöglicht. Der Port wird auch nützlich sein, um isolierte Ausführungen von Anwendungen mithilfe von WASI (WebAssembly System Interface) zu organisieren.
In den Plänen werden Experimente zur Implementierung von Grafikunterstützung in Umgebungen mit einem in WebAssembly gebauten Kernel erwähnt – auf Basis der Browser-API WebGL plant man die Implementierung von EGL und die Unterstützung von OpenGL ES. Zudem ist eine Unterstützung des Debugging-Formats Dwarf für die zeilenweise Code-Debugging vorgesehen.
Quelle: opennet.ru
