{"id":147115,"date":"2025-11-02T11:12:32","date_gmt":"2025-11-02T09:12:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlen-port-yadra-linux-dlya-webassembly-zapuskaemyj-v-brauzere"},"modified":"2025-11-02T11:12:32","modified_gmt":"2025-11-02T09:12:32","slug":"predstavlen-port-yadra-linux-dlya-webassembly-zapuskaemyj-v-brauzere","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/predstavlen-port-yadra-linux-dlya-webassembly-zapuskaemyj-v-brauzere","title":{"rendered":"Ein WebAssembly-Port des Linux-Kernels wurde vorgestellt, der im Browser ausgef\u00fchrt wird.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Mailingliste der Kernel-Entwickler von Linux wurden Patches ver\u00f6ffentlicht, die die Architektur \"Wasm\" f\u00fcr den Linux-Kernel implementieren. Diese erm\u00f6glicht es, den Kernel in WebAssembly-Intermediate-Code zu kompilieren, der direkt im Webbrowser ohne Einsatz von Emulatoren ausgef\u00fchrt werden kann. Zus\u00e4tzlich wurde f\u00fcr den Linux-Kernel die M\u00f6glichkeit geschaffen, ausf\u00fchrbare Dateien im Format \".wasm\" auszuf\u00fchren, und ein \"web console\"-Treiber zur Simulation der Konsolenarbeit im Browser vorbereitet. Au\u00dferdem wurde ein Toolset entwickelt, um die Erstellung von im Browser lauff\u00e4higen Systemumgebungen zu erleichtern. <\/p>\n
Als Beispiel wurde eine Umgebung auf der Basis von in WebAssembly kompilierten Utilities von BusyBox und der Systembibliothek musl erstellt. F\u00fcr die Arbeit mit einer solchen Umgebung wird Xterm.js als Terminalemulator eingesetzt. Separat wurde eine Demoseite gestartet, die es erm\u00f6glicht, die Funktionalit\u00e4t des Ports ohne eigene Kompilierung zu testen. Vollst\u00e4ndige Unterst\u00fctzung f\u00fcr Browser auf Chromium-Basis sowie eingeschr\u00e4nkte Unterst\u00fctzung f\u00fcr Firefox wurde angegeben, wobei die Debugging-M\u00f6glichkeiten dort begrenzt sind. Auf modernen Computern dauert das Laden der Wasm-Kernel-Build im Browser weniger als eine Sekunde. <\/p>\n
Das Projekt entwickelt sich bereits seit etwa zwei Jahren und erm\u00f6glicht es derzeit, den Kern in Browsern zu laden und g\u00e4ngige Programme auszuf\u00fchren. Die Arbeit ist noch nicht abgeschlossen, und der Port hat spezifische Probleme und Einschr\u00e4nkungen. Beispielsweise ist die Unterst\u00fctzung f\u00fcr die Aufrufe vfork und longjmp noch nicht implementiert (es wurden Patches f\u00fcr BusyBox verwendet, um ohne sie zu arbeiten), es gibt keine M\u00f6glichkeit, Aufgaben zu unterbrechen, und MMU ist nicht verf\u00fcgbar (Kern und Prozesse arbeiten im gleichen Adressraum). Es ist nicht m\u00f6glich, bereits geladenen Code zu \u00e4ndern, und nach etwa 5 Minuten kommt es aufgrund von Timerproblemen zu einem Konsolenhang. Es wird festgestellt, dass die bestehenden Einschr\u00e4nkungen \u00fcberwunden werden k\u00f6nnen, jedoch erfordert dies die Implementierung zus\u00e4tzlicher Erweiterungen zu WebAssembly in den Browsern f\u00fcr einige von ihnen. Solche Erweiterungen werden f\u00fcr MMU und das Anhalten von Threads vorgeschlagen. <\/p>\n
Die Unm\u00f6glichkeit, 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\u00f6glich, Prozesse parallel auszuf\u00fchren, dank der Browser-Engine und dem Kern des Host-Betriebssystems, ohne auf pr\u00e4emptives Multithreading und Task-Switching im Browser-Kern zur\u00fcckzugreifen. Unter dieser Konfiguration funktionieren Interrupts und Signale nicht vollst\u00e4ndig, und zur \u00dcbertragung von Timer-Interrupts und IPI (Inter-Processor Interrupt) wird ein separater virtueller CPU eingesetzt. <\/p>\n
Der Anwendungsbereich des Projekts geht \u00fcber das blo\u00dfe Starten von Linux-Umgebungen in Browsern hinaus. Zum Beispiel kann der Port zur Erstellung plattform\u00fcbergreifender 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\u00e4ngt werden, wodurch sie unabh\u00e4ngig vom Systemkern verwendet werden kann. Der Port wird auch n\u00fctzlich sein, um die isolierte Ausf\u00fchrung von Anwendungen mithilfe von WASI (WebAssembly System Interface) zu organisieren. <\/p>\n
Von den Pl\u00e4nen werden Experimente zur Unterst\u00fctzung von Grafik in Umgebungen mit einem in WebAssembly kompilierten Kern erw\u00e4hnt \u2013 auf Basis der Browser-API WebGL wird geplant, EGL zu implementieren und die Nutzung von OpenGL ES zu gew\u00e4hrleisten. Zudem ist die Implementierung des Dwarf-Debugging-Formats f\u00fcr die zeilenweise Code-Debugging vorgesehen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"