Une mise à jour dans la liste de diffusion des développeurs du noyau Linux a publié des correctifs implémentant l'architecture « Wasm » pour le noyau Linux, permettant de compiler le noyau en code intermédiaire WebAssembly pour une exécution directe dans le navigateur sans utiliser d'émulateurs. De plus, le projet a mis en œuvre la possibilité d'exécuter des fichiers au format « .wasm » et un pilote « web console » pour simuler le travail avec la console dans le navigateur. Un ensemble d'outils a également été préparé pour simplifier la compilation des environnements système exécutables dans le navigateur.
Comme exemple, un environnement basé sur les utilitaires BusyBox compilés en WebAssembly et la bibliothèque système musl a été formé. Xterm.js a été utilisé comme émulateur de terminal pour travailler avec un tel environnement. Un site de démonstration a été lancé séparément, permettant d'évaluer le fonctionnement du port sans compilation indépendante. Une pleine prise en charge des navigateurs basés sur Chromium et un support partiel pour Firefox, avec des fonctionnalités de débogage limitées, ont été annoncés. Sur les ordinateurs modernes, le chargement de l'assemblage Wasm du noyau dans le navigateur prend moins d'une seconde.
Le projet est en développement depuis environ deux ans et, à ce stade, permet de charger le noyau dans les navigateurs et d'exécuter des programmes typiques. Le travail n'est pas encore terminé et le port présente des problèmes et des limitations spécifiques. Par exemple, le support des appels vfork et longjmp n'est pas encore implémenté (des correctifs ont été appliqués à BusyBox pour fonctionner sans eux), l'interruption des tâches n'est pas possible, le MMU n'est pas accessible (le noyau et les processus fonctionnent dans le même espace d'adresses), il n'est pas possible de modifier le code déjà chargé, et la console se fige après environ 5 minutes en raison de problèmes de minuterie. Il est noté que les limitations existantes sont surmontables, mais certaines nécessitent la mise en œuvre d'extensions supplémentaires à WebAssembly dans les navigateurs. De telles extensions ont été proposées pour le MMU et la suspension des threads.
L'impossibilité de suspendre l'exécution des threads dans WebAssembly ne s'accorde pas avec le fonctionnement du planificateur de tâches dans le noyau, mais le multitâche a pu être réalisé de manière détournée, en liant chaque thread/tâche à son propre CPU virtuel, traité dans un Web Worker séparé. De cette manière, il a été possible d'atteindre l'exécution parallèle des processus grâce au moteur du navigateur et au noyau du système d'exploitation hôte sans recourir à un multitâche préemptif et au changement de tâches dans le noyau exécuté dans le navigateur. Les interruptions et les signaux dans ce schéma ne fonctionnent pas pleinement, et pour la livraison des interruptions du minuteur et les IPI (Inter-Processor Interrupt), un CPU virtuel séparé est utilisé.
Le champ d'application du projet dépasse le simple lancement d'environnements Linux dans les navigateurs. Par exemple, le port peut être utilisé pour créer des programmes WebAssembly multiplateformes utilisant des appels système spécifiques à Linux. La mise en œuvre de tels appels système peut être transformée en WebAssembly et attachée à l'application, permettant son utilisation sans lien avec le noyau système. Le port sera également utile pour organiser l'exécution isolée d'applications à l'aide de WASI (WebAssembly System Interface).
Parmi les projets, des expériences sont mentionnées concernant la prise en charge de la graphique dans des environnements avec un noyau compilé en WebAssembly — sur la base de l'API WebGL, il est prévu de réaliser EGL et d'assurer le fonctionnement d'OpenGL ES. Il est également prévu de mettre en œuvre le support du format de débogage Dwarf pour le débogage ligne par ligne du code.
Source : opennet.ru
