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 Intermediate WebAssembly-Code, der direkt im Webbrowser ohne den Einsatz von Emulatoren ausgefĂŒhrt werden kann. DarĂŒber hinaus wurde fĂŒr den Linux-Kernel die Möglichkeit geschaffen, ausfĂŒhrbare Dateien im Format â.wasmâ auszufĂŒhren, und ein Treiber fĂŒr die âWeb-Konsoleâ vorbereitet, um die Interaktion mit der Konsole im Browser zu simulieren. AuĂerdem wurde ein Werkzeugset zur Vereinfachung des Aufbaus von im Browser lauffĂ€higen Systemumgebungen erstellt.
Als Beispiel wurde eine Umgebung auf der Basis von in WebAssembly kompilierten Utilities von BusyBox und der Systembibliothek musl erstellt. FĂŒr die Arbeit mit einer solchen Umgebung wird Xterm.js als Terminalemulator eingesetzt. Separat wurde eine Demoseite gestartet, die es ermöglicht, die FunktionalitĂ€t des Ports ohne eigene Kompilierung zu testen. VollstĂ€ndige UnterstĂŒtzung fĂŒr Browser auf Chromium-Basis sowie eingeschrĂ€nkte UnterstĂŒtzung fĂŒr Firefox wurde angegeben, wobei die Debugging-Möglichkeiten dort begrenzt sind. Auf modernen Computern dauert das Laden der Wasm-Kernel-Build im Browser weniger als eine Sekunde.
Das Projekt entwickelt sich bereits seit etwa zwei Jahren und ermöglicht es derzeit, den Kern in Browsern zu laden und gĂ€ngige Programme auszufĂŒhren. Die Arbeit ist noch nicht abgeschlossen, und der Port hat spezifische Probleme und EinschrĂ€nkungen. Beispielsweise ist die UnterstĂŒtzung fĂŒr die Aufrufe vfork und longjmp noch nicht implementiert (es wurden Patches fĂŒr BusyBox verwendet, um ohne sie zu arbeiten), es gibt keine Möglichkeit, Aufgaben zu unterbrechen, und MMU ist nicht verfĂŒgbar (Kern und Prozesse arbeiten im gleichen Adressraum). Es ist nicht möglich, bereits geladenen Code zu Ă€ndern, und nach etwa 5 Minuten kommt es aufgrund von Timerproblemen zu einem Konsolenhang. Es wird festgestellt, dass die bestehenden EinschrĂ€nkungen ĂŒberwunden werden können, jedoch erfordert dies die Implementierung zusĂ€tzlicher Erweiterungen zu WebAssembly in den Browsern fĂŒr einige von ihnen. Solche Erweiterungen werden fĂŒr MMU und das Anhalten von Threads vorgeschlagen.
Die Unmöglichkeit, Threads in WebAssembly anzuhalten, steht im Widerspruch zur Funktionsweise des Task-Schedulers im Kern. Dennoch konnte Multithreading durch eine alternative Methode realisiert werden, indem jeder Thread/Aufgabe einem virtuellen CPU zugewiesen wird, der in einem separaten Web Worker verarbeitet wird. Auf diese Weise wurde es möglich, Prozesse parallel auszufĂŒhren, dank der Browser-Engine und dem Kern des Host-Betriebssystems, ohne auf prĂ€emptives Multithreading und Task-Switching im Browser-Kern zurĂŒckzugreifen. Unter dieser Konfiguration funktionieren Interrupts und Signale nicht vollstĂ€ndig, und zur Ăbertragung von Timer-Interrupts und IPI (Inter-Processor Interrupt) wird ein separater virtueller 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 spezifische systemeigene Aufrufe von Linux nutzen. Die Implementierung solcher systemeigenen Aufrufe kann separat in WebAssembly umgewandelt und an die Anwendung angehĂ€ngt werden, wodurch sie unabhĂ€ngig vom Systemkern verwendet werden kann. Der Port wird auch nĂŒtzlich sein, um die isolierte AusfĂŒhrung von Anwendungen mithilfe von WASI (WebAssembly System Interface) zu organisieren.
Unter den PlĂ€nen werden Experimente zur Implementierung von GrafikunterstĂŒtzung in Umgebungen mit einem in WebAssembly kompilierten Kernel erwĂ€hnt. Auf der Grundlage der Browser-API WebGL ist geplant, EGL zu implementieren und die FunktionalitĂ€t von OpenGL ES bereitzustellen. Es ist auch geplant, UnterstĂŒtzung fĂŒr das Debugging-Format Dwarf fĂŒr die zeilenweise Debugging von Code zu realisieren.
Quelle: opennet.ru
