- L’architecture des sous-systèmes de Windows NT a historiquement reposé sur une couche de conversion des appels API pour exécuter des programmes d’autres systèmes d’exploitation
- WSL1 s’inscrivait dans cette continuité : en tant que couche de traduction légère, il convertissait les appels Linux en appels du noyau Windows
- WSL2 a basculé vers une VM Linux complète basée sur Hyper-V pour résoudre les problèmes de performance, et exécute un noyau Linux réel
- WSL2 propose une intégration plus poussée que les VM classiques grâce à la gestion dynamique de la mémoire, le montage des lecteurs Windows et l’intégration GUI via WSLg
- Malgré des limites (gestion des fichiers peu pratique, dépendance aux images disque), la souplesse de tirer parti des forces et des faiblesses de WSL1 et WSL2 selon le cas d’usage reste essentielle
Le concept de sous-système dans Windows NT
- Le sous-système (subsystem) de Windows NT désigne un jeu d’API et une couche de conversion d’appels pour exécuter des programmes d’autres systèmes d’exploitation
- NT proposait autrefois des sous-systèmes comme OS/2 subsystem (OS2SS.EXE), POSIX subsystem (PSXSS.EXE), etc.
- CSRSS.EXE est une couche de conversion de l’API Win32, dont certaines fonctions ont été déplacées en mode noyau (
WIN32K.SYS)
- Le sous-système POSIX était une implémentation minimale pour certification gouvernementale, puis a été remplacé par Interix-based Windows Services for Unix
WSL1 : couche Linux basée sur la traduction
- WSL1 (Windows Subsystem for Linux) est une couche de traduction légère qui convertit les appels système Linux en appels Windows
- À l’exécution, le processus
bashutilise seulement quelques Mo de mémoire et apparaît comme un processus normal dans le Gestionnaire des tâches - La racine du système de fichiers existe comme une structure de fichiers individuelle sur NTFS, avec très peu de surcharge de stockage
- À l’exécution, le processus
- Limites
- Dégradation des performances I/O : coût de conversion lié aux différences entre les API de fichier Linux et Win32
- Serveur X externe requis pour exécuter une GUI (par ex. X410)
- Raw sockets non pris en charge, ce qui empêche l’exécution de
traceroute,nmap,tcpdump, etc.
WSL2 : VM Linux basée sur Hyper-V
- Face aux besoins des utilisateurs, Microsoft a introduit une VM Linux complète fonctionnant sur Hyper-V
- La racine du système de fichiers est gérée via un fichier VHDX unique
- La conversion WSL1↔WSL2 est possible avec la commande
wsl --set-version "Ubuntu" 2
- Caractéristiques de performance
- Le démarrage initial est plus lent, mais il exécute un noyau Linux natif
- L’utilisation mémoire est dynamique et peut monter jusqu’à la moitié de la mémoire physique maximale
- Dans le test
stress, l’usage mémoire augmente avec la charge puis se réduit automatiquement - Lorsque nécessaire, la VM peut être arrêtée avec la commande
wsl --shutdown
Intégration et limites de WSL2
- WSL2 renforce l’intégration avec Windows par rapport à une VM traditionnelle
- Montage automatique des lecteurs Windows, accès aux lecteurs Linux via le chemin
\\wsl$\\, exécution d’apps GUI via WSLg - Les applications GUI sont diffusées via le Remote Desktop Protocol, avec un réglage spécifique requis pour le DPI et la mise à l’échelle du texte
- Montage automatique des lecteurs Windows, accès aux lecteurs Linux via le chemin
- Problèmes de gestion des fichiers
- Les données de travail Linux sont stockées dans l’image
ext4.vhdx, avec des risques de portabilité et de récupération - L’exécution de
wsl --unregister Distrosupprime immédiatement toutes les données - Utiliser les lecteurs Windows (
/mnt/c) entraîne des baisses de performance dues à la surcharge NTFS + VM
- Les données de travail Linux sont stockées dans l’image
- Protocoles de système de fichiers
- WSL1 utilise
drvfs, WSL2 utilise le protocole9pde Plan9 - Des cas de bugs résiduels liés à
drvfssont mentionnés pendant les conversions
- WSL1 utilise
- Alternative
- Il est recommandé de créer une image VHDX séparée et de la monter avec
wsl --mount --vhdpour isoler les données de travail - La configuration automatique n’est pas possible dans
.wslconfig, il faut la piloter via des scripts
- Il est recommandé de créer une image VHDX séparée et de la monter avec
Conclusion
- La conception modulaire de Windows NT et son ABI noyau stable préservent la compatibilité avec d’anciens pilotes
- WSL1 a l’avantage d’une faible consommation mémoire, tandis que WSL2 apporte une compatibilité et des performances supérieures avec un noyau Linux réel
- WSL2 est une architecture qui minimise les inconvénients d’une VM tout en renforçant l’intégration avec l’OS hôte
- Selon la définition classique, il s’apparente à une VM, mais il mérite d’être considéré comme un « sous-système » grâce à son intégration légère
3 commentaires
Waouh, il y a aussi le développeur Sseuk.
Avis Hacker News
WSL2 fonctionne sur un sous-ensemble de Hyper-V et est, fondamentalement, une VM au-dessus de l’hyperviseur
Mais il diffère d’une VM Hyper-V classique. Par exemple, les distributions Linux de WSL2 peuvent utiliser l’accélération GPU même dans des environnements X ou Wayland grâce au partitionnement GPU (c’est-à-dire le passthrough PCI/GPU) et à une implémentation spéciale de DirectX
Ce genre de fonctionnalité est aussi possible sur un Hyper-V classique via des bricolages avec PowerShell, mais officiellement, ce n’est pris en charge que sur Windows Server
En revanche, dire que « X ou Wayland s’occupent du rendu » est trompeur. En réalité, c’est l’application elle-même qui utilise le GPU, et X/Wayland ne gèrent essentiellement que la composition des fenêtres une fois le rendu terminé
Il y a aussi des opérations plus complexes comme la conversion des couleurs, mais la charge de calcul reste faible
WSL1 reposait sur les pico process, une technologie dérivée de la recherche Drawbridge
Voir les ressources The Linux Kernel Hidden Inside Windows 10 et WSL Pico Process Overview
La même technologie Drawbridge a aussi été utilisée pour exécuter SQL Server sur Linux
L’article d’Ars Technica l’explique en détail
Je comprends pourquoi ils sont passés à WSL2, mais c’est dommage d’avoir complètement arrêté le développement de WSL1
Notre environnement de CI est majoritairement basé sur Linux, mais certaines toolchains ne fonctionnent pas bien sous Wine, comme MSVC
Nous avions donc besoin d’un environnement capable d’exécuter correctement des builds Linux depuis Windows. WSL1 le permettait, mais WSL2 ne partage ni les espaces de noms de processus ni les descripteurs de fichiers, ce qui oblige à recourir à diverses solutions de contournement
Les performances d’E/S se sont améliorées, mais le partage de fichiers est lent, donc peu adapté à un usage réel
/mnt/cJ’ai déjà compilé des modules d’extension C pour Python de cette manière
WSL2 est une VM très étroitement intégrée à l’environnement Windows
Je l’utilise tous les jours pour le développement parce que la politique de l’entreprise m’impose Windows, et dans la plupart des cas l’expérience est assez confortable
En revanche, comme nous sommes sur une base RHEL8, le fait que seules les distributions de type Debian soient prises en charge est gênant. Je me demande aussi où en est aujourd’hui le support des applications graphiques
psoutop, on ne voit que les processus de la VM.On peut obtenir quelque chose de similaire avec
docker run -it ubuntu, donc je me demande quelle est la vraie différence.Personnellement, cet espace de travail séparé m’a beaucoup dérangé
WSL2 est au fond une VM légère. Le concept est proche de Firecracker, avec pour objectif un démarrage rapide et une faible consommation mémoire
Mais dès qu’on lance plusieurs conteneurs Docker, les besoins en mémoire augmentent. Il faut au moins 20 Go pour être vraiment à l’aise
Personnellement, je trouve WSL1 bien plus utile. La plupart des outils CLI comme les toolchains C++ et .NET, ainsi que ssh/scp, fonctionnent très bien
À l’inverse, WSL2 ne me sert quasiment à rien. Quand j’ai besoin d’une VM Linux, j’utilise VMware
VMware offre beaucoup plus de fonctionnalités, comme les arbres de snapshots, l’accélération 3D, la connexion de périphériques USB, la configuration réseau virtuelle, ainsi qu’une interface graphique pratique
Le disque de la VM interne à WSL est accessible via le chemin
\\wsl$Si un ancien logiciel ne prend pas en charge les chemins UNC, on peut contourner le problème en les associant à une lettre de lecteur
Il y a un problème où le fichier VHDX continue de grossir. Il faut le compacter manuellement
systemd-trimpeut résoudre une partie du problèmeVoir aussi GitHub WSL #12103
Et si cela ne suffit pas, on peut utiliser cette méthode d’optimisation manuelle
À noter que WSL contourne par défaut les règles du pare-feu Windows. On peut se demander pourquoi Microsoft l’a conçu ainsi
Je me demande s’il serait possible de monter une vraie partition ext4 afin de réduire la perte de performances liée à la simulation d’un périphérique bloc basée sur un fichier image
Alors que j’utilise de plus en plus souvent WSL2 et que j’en viens peu à peu à moins utiliser Linux directement, je me demande si ce n’est pas aussi une forme d’EEE.
EEE - adopter, étendre et éliminer (Embrace, Extend, and Extinguish)