{"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\/news\/predstavlen-port-yadra-linux-dlya-webassembly-zapuskaemyj-v-brauzere","title":{"rendered":"Ein Port des Linux-Kernels f\u00fcr WebAssembly wurde vorgestellt, der im Browser ausgef\u00fchrt werden kann.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Mailingliste der Linux-Kernel-Entwickler wurden Patches ver\u00f6ffentlicht, die die Architektur «Wasm» f\u00fcr den Linux-Kernel implementieren. Diese erm\u00f6glicht es, den Kernel in Zwischencode von WebAssembly zu kompilieren, der anschlie\u00dfend direkt im Webbrowser ohne den Einsatz von Emulatoren ausgef\u00fchrt werden kann. Dar\u00fcber hinaus hat das Projekt f\u00fcr den Linux-Kernel die M\u00f6glichkeit implementiert, ausf\u00fchrbare Dateien im Format «.wasm» auszuf\u00fchren, und einen «web console» Treiber vorbereitet, um die Arbeit mit der Konsole im Browser zu simulieren. Ein Werkzeugset wurde ebenfalls vorbereitet, um die Erstellung von im Browser ausf\u00fchrbaren Systemumgebungen zu erleichtern. <\/p>\n
Als Beispiel wurde eine Umgebung auf Basis der in WebAssembly kompilierten Utils von BusyBox und der Systembibliothek musl geschaffen. F\u00fcr die Arbeit mit einer solchen Umgebung wird Xterm.js als Terminalemulator verwendet. Separat wurde eine Demowebsite gestartet, die es erm\u00f6glicht, die Arbeit des Ports zu bewerten, ohne selbst zu kompilieren. Es wird vollst\u00e4ndige Unterst\u00fctzung f\u00fcr Browser auf Chromium-Basis und teilweise Unterst\u00fctzung f\u00fcr Firefox angek\u00fcndigt, in dem die Debugging-M\u00f6glichkeiten eingeschr\u00e4nkt sind. Auf modernen Computern dauert das Laden des Wasm-Kernels im Browser weniger als eine Sekunde. <\/p>\n
Das Projekt entwickelt sich bereits seit etwa zwei Jahren und erm\u00f6glicht es derzeit, den Kernel in Browsern zu laden und typische Programme auszuf\u00fchren. Die Arbeit ist noch nicht abgeschlossen, und der Port hat einige Probleme und Einschr\u00e4nkungen. So wird beispielsweise die Unterst\u00fctzung f\u00fcr die Aufrufe vfork und longjmp noch nicht bereitgestellt (f\u00fcr BusyBox wurden Patches angewendet, um ohne sie zu arbeiten), die M\u00f6glichkeit, Aufgaben zu unterbrechen, fehlt, und der MMU ist nicht verf\u00fcgbar (Kernel und Prozesse arbeiten im selben Adressraum). Es ist nicht m\u00f6glich, bereits geladenen Code zu \u00e4ndern, und die Konsole friert nach etwa 5 Minuten aufgrund von Timer-Problemen ein. Es wird darauf hingewiesen, dass die vorhandenen Einschr\u00e4nkungen \u00fcberwindbar sind, aber f\u00fcr einige von ihnen die Implementierung zus\u00e4tzlicher Erweiterungen f\u00fcr WebAssembly in Browsern erforderlich ist. Solche Erweiterungen wurden f\u00fcr MMU und die Unterbrechung von Threads vorgeschlagen. <\/p>\n
Die Unm\u00f6glichkeit, die Ausf\u00fchrung von Threads in WebAssembly anzuhalten, steht im Widerspruch zur Arbeitsweise des Task-Schedulers im Kernel. Allerdings konnte Multitasking \u00fcber 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\u00f6glich, die parallele Ausf\u00fchrung 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\u00fcckzugreifen. Unterbrechungen und Signale funktionieren in diesem Schema nicht vollst\u00e4ndig, und um Timer-Interrupts und IPI (Inter-Processor Interrupt) zu liefern, wird eine separate virtuelle 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 linux-spezifische Systemaufrufe nutzen. Die Implementierung solcher Systemaufrufe kann separat in WebAssembly umgewandelt und an die Anwendung angeh\u00e4ngt werden, was die Nutzung unabh\u00e4ngig vom Systems Kernel erm\u00f6glicht. Der Port wird auch n\u00fctzlich sein, um isolierte Ausf\u00fchrungen von Anwendungen mithilfe von WASI (WebAssembly System Interface) zu organisieren. <\/p>\n
Von den Pl\u00e4nen wird die Experimentierung zur Implementierung von Grafikunterst\u00fctzung in Umgebungen mit einem auf WebAssembly aufgebauten Kernel erw\u00e4hnt \u2014 basierend auf der Browser-API WebGL ist geplant, EGL zu implementieren und OpenGL ES zum Laufen zu bringen. Au\u00dferdem wird angestrebt, das Debugging-Format Dwarf f\u00fcr die zeilenweise Code-Debugging zu unterst\u00fctzen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"