Haiku est un système d’exploitation libre destiné aux ordinateurs personnels ou de bureau (pas de serveurs, pas de systèmes embarqués, pas de tablettes ni de téléphones). Il s’agit au départ d’une réécriture libre de BeOS, préservant la compatibilité binaire avec ce dernier (les applications BeOS peuvent tourner sur certaines versions de Haiku).

Après la présentation des applications de Haiku, voici une incursion dans le noyau et la chaîne de compilation. Au menu de ce chapitre notamment : processeurs, réseau, périphériques, son et image, système de fichier, améliorations des performances, etc.

Sommaire

• Noyau
  • Pilotes
    • Processeurs
    • Réseau
    • Périphériques d’entrée
    • Son et image
    • Machines virtuelles
    • Autres
  • Systèmes de fichiers
  • Réseau
    • Sockets UNIX
    •  TCP
  • Autres
  • Portages ARM, RISC-V et autres
• Bootloader
• Amélioration de performances
  • Implémentation des IO vectorisées sur les périphériques de type bloc
  • Réparation du profiler
  • Réduction des verrouillages du device manager
  • DT_GNU_HASH dans les fichiers ELF
  • premapping de mmap
  • Suppression des zones mémoire
  • Calcul des sommes de contrôles des paquets réseau par le matériel
  • user_mutex
• Chaîne de compilation

Noyau

Le noyau de Haiku est similaire à celui de BeOS : il s’agit d’un noyau monolithique, avec du multitâche préemptif et protection mémoire. Rien de très inhabituel. Il est développé en C++ (comme le reste du système), ce qui permet de rendre le code plus lisible que du C tout en conservant des bonnes performances pour ce code bas niveau.

Un point intéressant, le noyau offre une API et une ABI stable pour les pilotes, ce qui fait qu’il est en théorie possible de développer un pilote hors du projet Haiku et de le faire fonctionner avec plusieurs versions du noyau. En pratique, peu de personnes se lancent dans ce genre de chose, il est plus simple d’intégrer les pilotes dans le dépôt de sources de Haiku pour l’instant.

Pilotes

Commençons justement par regarder les nouveautés du côté des pilotes matériels. Il s’agit pour tout système d’exploitation d’un point de difficulté, indispensable pour fonctionner sur une large variété de systèmes.

Processeurs

En principe, un processeur est un matériel assez bien standardisé, qui implémente un jeu d’instruction bien défini et ne devrait pas nécessiter de pilote spécifique. Cependant, le matériel moderne de plus en plus complexe, offrant de plus en plus de fonctionnalités dans une seule puce électronique, fait qu’il faut tout de même prendre en compte quelques cas particuliers.

• Ajout de nouvelles générations de machines Intel dans le driver PCH thermal (récupération de la température du CPU au travers du platform control hub).
• Implémentation du contournement pour la faille Zenbleed dans les processeurs AMD.
• La mise à jour du microcode pour les processeurs Intel n’est pas faite si le CPU est déjà à jour (pour gagner un peu de temps au redémarrage du système).

Réseau

Les cartes réseau restent aujourd’hui le composant le moins bien standardisé sur les ordinateurs. Il n’existe pas d’interface standardisée, et chaque fabricant propose sa propre façon de faire.

Aujourd’hui, la plupart des autres périphériques suivent des spécifications (xHCI pour les contrôleurs USB3, AHCI pour le SATA, Intel HDA pour les cartes son…) ou bien il ne reste que peu de concepteurs de composants (par exemple pour les cartes graphiques où on ne trouve que Intel, AMD et NVidia).

Écrire des pilotes pour toutes ces cartes réseau demanderait beaucoup trop de travail. C’est pourquoi, depuis 2007, Haiku s’est doté d’une couche de compatibilité avec FreeBSD, permettant de réutiliser les pilotes écrits pour ce dernier (une approche également utilisée par le système d’exploitation temps réel RTEMS).

Cependant, les développeurs de FreeBSD font face au même problème, et ont décidé d’adopter la même solution : une couche de compatibilité permettant d’utiliser les pilotes de Linux. Cela pose deux problèmes pour Haiku : il ne semble pas souhaitable d’empiler les couches de compatibilité, et il ne semble pas raisonnable d’écrire une couche de compatibilité avec Linux, dont les API internes évoluent beaucoup trop vite, ce qui nécessiterait une réécriture permanente de la couche de compatibilité pour suivre le rythme.

Finalement, la solution retenue pour Haiku est d’utiliser les pilotes activement développés par OpenBSD et en particulier par Stefan Sperling. La couche de compatibilité avec FreeBSD est également maintenue, et Haiku bénéficie donc des pilotes développés pour ces deux systèmes, en plus des siens propres.

Par exemple, les pilotes wifi iaxwifi200 et idualwifi7260 proviennent de OpenBSD, tandis que ipro1000 et intel22x sont ceux de FreeBSD 14. Les couches de compatibilité reçoivent régulièrement des corrections et améliorations.

En dehors des cartes réseaux physiques, Haiku dispose d’un nouveau pilote tun permettant de créeer des tunnels réseau. Celui-ci a été développé dans le cadre du Google Summer of Code 2023, et permet par exemple d’utiliser un client OpenVPN sous Haiku.

Enfin, une évolution qui concerne tous les pilotes réseaux : le nombre de paquets et d’octets reçus et envoyés pour une interface réseau est maintenant décompté par la pile réseau, plutôt que par chaque pilote d’interface réseau. Les pilotes doivent toujours tenir à jour les compteurs d’erreurs. Ce changement permet de regrouper le code de comptage à un seul endroit, et d’éviter des comportements différents entre pilotes. En particulier, le comptage des paquets pour l’interface localhost n’était pas correct.

Périphériques d’entrée

Haiku permet d’utiliser les claviers et souris connectés en USB et en PS/2 (encore utilisé dans certains ordinateurs portables, mais il semble en voie de disparition). Les pilotes pour les touchpads et claviers i2c sont encore en cours de développement, et le Bluetooth arrivera un peu plus tard.

Commençons par le pilote PS/2. Il reçoit relativement peu d’évolutions, cependant, les ordinateurs portables récents n’implémentent plus forcément complètement le matériel nécessaire (l’interface PS/2 étant simulée par l'embedded controller). Le pilote PS/2 de Haiku qui essaie de détecter de nombreux cas de configuration possibles est parfois un peu dérouté par ces écarts. Cela pouvait provoquer un blocage empêchant d’utiliser le clavier pendant plusieurs secondes après le lancement de la machine, le temps que le pilote finisse d’énumérer les périphériques PS/2. Le problème a été corrigé en réduisant le temps d’attente avant de décider qu’il n’y a aucun périphérique connecté.

Du côté de l’USB, une première correction concerne la prise en compte de l’attribut « minimum » dans les rapports HID. Le protocole HID permet de définir toutes sortes de périphériques (claviers, souris, mais aussi clubs de golf, simulateurs de tanks…). Les périphériques USB HID envoient à l’ordinateur une description des contrôles dont ils disposent (groupes de boutons, axes, etc). Pour les boutons et touches de clavier, la valeur « minimum » indique le code du premier bouton dans le groupe, les autres étant déduits en incrémentant la valeur pour chaque bouton présent. Ce cas n’était pas bien pris en compte par le pilote de clavier, ce qui provoquait l’envoi de mauvais codes aux applications pour les claviers concernés.

D’autre part, et de façon plus spécifique, le pilote de souris bénéficie maintenant d’un quirk, c’est-à-dire d’une procédure de contournement d’un problème, pour les souris et trackballs de la marque Elecom. Ces dernières utilisent en effet toutes le même descripteur HID, indiquant la présence de 5 boutons, alors que certains modèles ont en fait un 6^me bouton non déclaré. Le descripteur est corrigé à la volée pour les périphériques concernés.

Son et image

Haiku dispose d’un pilote pour les périphériques USB Audio. Ce pilote est en développement depuis très longtemps (cela remonte avant l’apparition de l’USB 2.0), mais il n’avait jamais pu être finalisé en raison du manque de prise en charge des transferts isochrones. Ces problèmes ont enfin été corrigés, mais le pilote nécessite encore des travaux pour le rendre compatible avec plus de matériel (en particulier les périphériques implémentant la version 2.0 de la spécification USB Audio) et probablement également quelques corrections dans le serveur média pour le préparer à l’apparition et la disparition de cartes son pendant que le système est en train de tourner (actuellement, cela nécessitera un redémarrage du serveur).

Du côté des cartes son PCI, pas de grande nouveauté, mais un gros nettoyage dans le cadre de travaux pour supprimer tous les avertissements du compilateur. Ce travail se fait petit à petit, dossier par dossier dans le code de Haiku. L’analyse du dossier contenant les pilotes de cartes son a révélé l’existence de trois pilotes ciblant le même matériel, ainsi que de plusieurs fichiers qui avaient été dupliqués dans plusieurs pilotes (développés avant leur rassemblement dans le dépôt de sources de Haiku à partir du mème exemple de code), puis qui avaient divergé au cours du développement de chaque pilote. Ce code a été réunifié dans une version partagée qui inclut toutes les corrections et améliorations de chaque version.

Du côté des cartes graphiques, des travaux sont en cours pour pouvoir piloter correctement les cartes graphiques Intel de 12^me génération. Le pilote existant fonctionne déjà dans certains cas, mais se repose beaucoup sur le travail fait par le firmware (BIOS ou EFI) pour initialiser l’affichage. Il est ainsi impossible d’utiliser un écran qui n’a pas été configuré au démarrage de la machine (passer d’une sortie HDMI à l’écran d’un PC portable ou inversement, par exemple).

Machines virtuelles

Haiku est utilisé dans des machines virtuelles pour diverses raisons : à des fins de test par les développeurs, pour l’infrastructure de compilation des paquets, ou encore par des utilisateurs qui veulent le tester sans l’installer sur une machine physique dédiée.

Des pilotes spécifiques et quelques adaptations sont nécessaires pour un bon fonctionnement sur ces machines. En particulier, des pilotes sont nécessaires pour certains périphériques virtio, qui permettent aux machines virtuelles d’émuler un matériel simplifié, ne correspondant pas à un matériel réel existant. Ceci permet de meilleures performances.

Le pilote virtio de Haiku a été mis à jour pour implémenter la version 1.0 de la spécification. Cela a permis de corriger des problèmes dans le pilote virtio_block (support de stockage virtualisé).

Un nouveau pilote virtio_gpu permet l’affichage de l’écran sans avoir à passer par un pilote pour une carte graphique, ni par les pilotes VESA ou framebuffer EFI qui montrent assez vite leurs limitations (choix de résolutions d’écran limité, par exemple). Plus tard, ce pilote pourrait permettre également d’expérimenter avec la virtualisation de OpenGL, et donc d’expérimenter avec l’accélération du rendu 3D sans avoir à développer un pilote graphique capable de le faire.

Ces pilotes virtualisés facilitent également le travail de portage de Haiku vers de nouvelles architectures : il est possible de lancer Haiku dans QEMU avec n’importe quel processeur, et un ensemble de périphériques virtio pour lesquels les pilotes ont pu d’abord être testés sur une autre architecture déjà fonctionnelle.

Autres

La bibliothèque ACPICA a été mise à jour avec la dernière version 20230628, et les changements nécessaires pour son fonctionnement dans Haiku ont été intégrées en amont, ce qui facilitera les prochaines mises à jour. ACPICA est développée par Intel et permet d’implémenter la spécification ACPI, pour la gestion d’énergie, l’énumération du matériel présent sur une machine, et diverses fonctionnalités liées (détection de la fermeture d’un ordinateur portable, récupération du niveau de charge des batteries, par exemple).

Le pilote poke, qui permet aux applications de manipuler directement la mémoire physique sans l’aide d’un pilote spécifique, a été remis à jour et finalisé. Il est utile principalement pour expérimenter avec le matériel avant de développer un pilote spécifique.

La pile Bluetooth a reçu un premier coup de nettoyage. Pas de grosses évolutions pour l’instant, seules les couches les plus basses sont implémentées, on pourra au mieux énumérer les périphériques Bluetooth présents à proximité. Le développement des fonctionnalités suivantes attendra au moins la publication de la version Bêta 5.

Systèmes de fichiers

Haiku implémente plusieurs systèmes de fichiers. Celui utilisé pour le système est BFS, hérité de BeOS et qui fournit quelques fonctions indispensables à Haiku (comme les requêtes qui permettent d’indexer des attributs étendus de fichiers dans une base de données). Mais de nombreux autres systèmes de fichiers peuvent être lus, et pour certains, écrits. Cela permet de facilement partager des fichiers avec d’autres systèmes d’exploitation.

Le système de fichier UFS2 est maintenant complètement implémenté (en lecture seule), inter-opérable avec FreeBSD, et sera disponible dans l’installation de base pour les prochaines versions de Haiku.

Du côté de Linux, l’interopérabilité est possible en lecture et en écriture avec les systèmes de fichiers ext2, 3, et 4 (tous les 3 implémentés dans un seul pilote qui sait les reconnaître et les différencier). Cette implémentation a reçu quelques corrections de bugs ainsi qu’une implémentation de F_SETFL.

Enfin du côté de Windows, la prise en charge de NTFS avait déjà été mise à jour et grandement améliorée (en réutilisant les sources de NTFS-3g). Cette année, c’est le tour des systèmes de fichiers FAT. Le pilote utilisé jusqu’à maintenant avait été publié par Be il y a très longtemps. Il avait été mis à jour pour Haiku mais comportait de nombreux problèmes : mauvaise gestion des dates de modification des fichiers, interopérabilité avec d’autres implémentations, voire crash du système lors de tentative de lecture de partitions corrompues. Ce code a été entièrement remplacé par un pilote utilisant l’implémentation du FAT de FreeBSD.

Enfin, le système de fichier ramfs (pour stocker des fichiers dans la RAM de l’ordinateur de façon non persistente) a reçu des corrections sur la fonction preallocate. Cela corrige en particulier des fuites de mémoire dans les navigateurs web basés sur QWebEngine, qui utilisent ce système de fichiers pour partager de la mémoire entre plusieurs processus.

Un changement un peu plus global, et pas lié à un système de fichier spécifique, est la réunification du code pour parser les requêtes. Il s’agit d’une méthode pour rechercher des fichiers à partir de leurs attributs étendus (xattrs) qui sont indexés à la façon d’une base de données. Au départ, cette fonctionnalité était propre au système de fichier BFS, mais elle a été implémentée également pour ramfs et packagefs (système de fichier permettant d’accéder au contenu des paquets logiciels sans les décompresser). Lors du développement de ces deux nouveaux systèmes de fichiers, le code permettant de convertir une chaîne de caractères exprimant une requête en opération exécutable avait été extrait du pilote BFS pour en faire un module générique. Mais le pilote BFS n’avait pas encore été mis à jour pour utiliser ce module. C’est désormais chose faite, ce qui assure que le comportement entre les 3 systèmes de fichiers est le même, et que les corrections de bugs bénéficieront à tous les trois.

Pour terminer sur les systèmes de fichiers, l’outil fs_shell, qui permet d’exécuter le code d’un système de fichier en espace utilisateur, a reçu deux nouvelles commandes : truncate et touch. Cet outil permet de tester les systèmes de fichiers en cours de développement dans un environnement plus confortable et mieux contrôlé, et il est aussi utilisé lors de la compilation de Haiku pour générer les images disques.

Réseau

La pile réseau proprement dite a principalement évolué avec de la mise en commun de code. Par exemple, l’implémentation de l’ioctl FIONBIO (non standardisé, mais largement implémenté) pour passer un descripteur de fichier en mode non bloquant a été réécrite pour partager du code avec le flag O_NONBLOCK configurable par fcntl et F_SETFL. Également, le flag MSG_PEEK qui permet de lire des données d’un socket sans les retirer de son buffer de réception, est maintenant implémenté directement par la pile réseau au lieu d’avoir une version spécifique à chaque type de socket.

Sockets UNIX

Les sockets de la famille AF_UNIX sont utilisés pour les communications locales entre applications sur une même machine. Ils sont en particulier utilisés par WebKit et de nombreux autres moteurs de rendu web, mais assez peu par les applications natives pour Haiku, qui disposent d’autres méthodes de communications (en particullier les BMessage et les ports).

L’implémentation des sockets UNIX est maintenant complète et suffisante pour faire fonctionner toutes les applications qui en ont l’utilité.

 TCP

La pile TCP de Haiku est devenue au fil du temps un goulot d’étranglement des performances. D’une part parce que toutes les autres parties du système se sont améliorées, et d’autre part parce que les interfaces réseaux sont de plus en plus rapides et de plus en plus sollicitées.

Le travail sur la pile TCP cette année a commencé par la remise en route de l’outil tcp_shell, qui permet de tester l’implémentation de TCP en espace utilisateur et en isolation du reste du système. Cet outil avait été utilisé au tout début du développement de la pile TCP, mais n’avait pas été tenu à jour depuis. Il permet maintenant de tester la pile TCP communiquant avec elle-même, et aussi d’injecter des paquets à partir de fichier pcap. Pour l’instant, la fonction permettant de communiquer avec l’extérieur n’a pas été remise en place.

Cet outil a permis d’identifier et d’analyser certains des problèmes rencontrés.

Le premier problème était un envoi d’acquittements TCP en double. À première vue, cela ne devrait pas poser de gros problèmes, il y a seulement un peu de redondance. Mais, en pratique, une implémentation de TCP qui reçoit des acquittements en double suppose qu’il y a eu un problème de congestion réseau lors de l’envoi de données dans l’autre sens. Les algorithmes de contrôle de la congestion se mettent en jeu, et le trafic ralentit pour éviter une congestion qui n’existe pas. Par exemple, la taille de la fenêtre de transmission TCP (le nombre maximum d’octets qui peuvent être envoyés sans attendre d’acquittement) peut être réduite.

Et, malheureusement, cela déclenche un autre problème : la taille de cette fenêtre peut atteindre 0 octet, et dans ce cas, HAiku ne s’autorisait plus à émettre aucun paquet. Cela pouvait se produire au même moment dans les deux directions sur une connexion TCP, ce qui fait qu’aucune des deux machines connectées ne s’autorise à envoyer de données à l’autre. Ce problème a été corrigé, les transmissions peuvent maintenant continuer à débit réduit, puis reprendre une vitesse optimale petit à petit.

Après ces corrections, une mesure des performances de TCP dans un environnement de test montre que la pile TCP est capable de traiter jusqu’à 5.4 Gbits/s de trafic, alors que le débit plafonnait à 45 Mbits/s auparavant. C’est donc un centuplage des performances.

Autres

Plusieurs autres évolutions diverses dans le noyau :

L’implémentation de kqueue, ajoutée l’année dernière, a reçu plusieurs corrections et améliorations. Elle couvre déjà plusieurs usages et permet l’utilisation de plus de logiciels portés depuis d’autres systèmes, mais les cas d’utilisation les plus avancés ne sont pas encore tout à fait fonctionnels.

Pour rappel, kqueue est une fonction des systèmes BSD permettant à un thread utilisateur de se mettre en attente de plusieurs types d’évènements et de ressources du noyau. L’usage est similaire à celui de epoll sous Linux mais l’API est différente.

La classe ConditionVariable, utilisée pour la synchronisation entre threads et interruptions dans le noyau, a reçu plusieurs mises à jour. Un article sur le site de Haiku détaille l’utilisation et le fonctionnement de cette classe.

La boucle principale du débugger noyau (KDL), qui prend la main sur tous les processeurs en cas de crash du système ou sur demande de l’utilisateur pour investiguer des problèmes, inclus maintenant une instruction PAUSE. Cela permet d’informer le CPU qu’il n’est pas nécessaire d’exécuter cette boucle à la vitesse maximale, évitant de faire surchauffer la machine sans raison. Cette boucle est principalement en attente d’instructions de l’utilisateur, via un clavier ou un port série.

Du refactoring sur les parties du code qui sont spécifiques à chaque architecture : arch_debug_get_caller est maintenant implémenté via un builtin gcc plutôt que du code assembleur à écrire à la main pour chaque machine. arch_debug_call_with_fault_handler appelait une fonction avec un mauvais alignement de pile sur x8_64, pouvant conduire à un crash si la fonction appelée utilisait des instructions SSE par exemple. Correction également d’un problème qui pouvait causer la perte d’une interruption inter-CPU (permettant à un cœur de processeur d’interrompre l’exécution de code en cours sur un autre cœur) dans certains cas.

Une modification sur la gestion des descripteurs de fichiers: la structure interne des descripteurs de fichiers était pourvue d’un champ indiquant le type (fichier, socket, pipe…). Ce champ et tout le code qui en dépendait ont été supprimés. Ceci permet à des add-ons du kernel de déclarer leurs propres types de fichiers sans avoir à modifier le noyau. Cela pourrait par exemple être utile pour développer une couche de compatibilité avec Linux, qui fait un usage généreux des descripteurs de fichiers de tous types (eventfd, signalfd, timerfd…).

Réécriture du code de debug activé par l’option B_DEBUG_SPINLOCK_CONTENTION qui permet d’investiguer les problèmes de performances liés à l’utilisation de spinlocks (attente active sur une interruption matérielle).

Un petit changement d’algorithme sur l’allocateur de pages du noyau. Cet allocateur alloue des pages mémoires par blocs multiples de 4Ko. Les pages libérées étaient réinsérées une par une dans une liste chaînée. Cela conduit à insérer les pages dans l’ordre inverse de leurs adresses (la dernière page d’une zone mémoire se retrouve au début de la liste). Lors des prochaines allocations, cette page se retrouve donc allouées en premier, puis celle qui se trouve juste avant, et ainsi de suite. La zone mémoire construite par toutes ses pages est donc considérée comme discontinue. En inversant l’ordre d’insertion des pages dans la liste, on préserve les pages dans un ordre globalement croissant d’adresse mémoire, et on augmente les chances qu’une allocation de plusieurs pages se trouve avec des pages contiguës et dans le bon ordre. Cela est utile en particulier pour les allocations qui vont être utilisées pour des transferts DMA: il sera possible de programmer un seul gros transfert DMA au lieu de plusieurs petits.

L’état de la FPU du processeur n’était pas complètement sauvegardé lors d’un changement de contexte. Certains drapeaux de configuration pouvaient donc rester positionnés avec les valeurs configurées par un thread, pendant l’exécution d’un autre. Au mieux cela donnait des résultats inattendus, au pire, un crash (par exemple si le FPU est configuré pour lever une exception matérielle, dans un thread qui ne s’y attend pas). Le nouveau code de sauvegarde utilise des instructions dédiées qui sauvegardent d’un coup tout l’état du FPU, ce qui fait qu’en plus de fonctionner correctement, il est plus rapide que ce qui était fait précédemment.

Une évolution sur les sémaphores: la fonction release_sem_etc permet de donner une valeur négative au paramètre « count ». Dans ce cas, le thread qui était en attente d’un acquire_sem sera réveillé, mais la fonction acquire_sem retournera une erreur indiquant que le sémaphore n’a pas pu être obtenu. Cela permet de simplifier un peu le code de certaines utilisations classiques des sémaphores.

Une correction de bug sur le code traitant les « doubles fautes ». Le fonctionnement d’un système d’exploitation est en partie basé sur l’interception des « fautes », par exemple, un programme qui essaie d’accéder à de la mémoire qui a été évacuée dans la swap. Cette mémoire n’est pas immédiatement accessible, le programme est donc interrompu, le noyau prend la main, va récupérer cette mémoire, puis rend la main au programme qui n’y voit que du feu et continue son exécution comme si de rien n’était. Les fautes peuvent également se produire dans le cas où un programme essaie d’accéder à une zone mémoire non allouée, on aura alors une erreur de segmentation.

Tout ça est très bien, mais que se passe-t-il si le code qui traite ces problèmes déclenche lui-même une faute ? C’est prévu : il existe un deuxième morceau de code qui va intercepter ces problèmes et tout arrêter pour lancer le debugger noyau, et permettre à un humain d’examiner la situation.

Oui, mais que se passe-t-il si ce code déclenche lui-même une faute ? C’est ce qu’on appelle une triple faute, dans ce cas, la solution de dernier recours est d’immédiatement redémarrer la machine.

Des utilisateurs se sont plaints de redémarrages intempestifs, et une étude attentive du code traitant les doubles fautes a révélé un problème qui déclenchait systématiquement une triple faute (difficile à analyser, car on n’a pas de journaux ou de moyen d’investiguer le problème). Espérons que l’accès au debugger noyau lors des doubles fautes permettra désormais de comprendre d’où elles proviennent.

Tout autre sujet, le noyau dispose maintenant d’APIs pour configurer l’affinité des threads, par exemple pour interdire à un thread de s’exécuter sur certains cœurs de processeurs. Cela peut être utile sur des machines avec des processeurs hétérogènes (par exemple ARM BIG.Little), ou encore si le développeur d’une application pense pouvoir faire mieux que l’ordonnanceur par défaut pour répartir ses threads sur différents cœurs.

Pour terminer sur les évolutions dans le noyau, la calibration du TSC peut maintenant être faite à partir d’informations obtenues via l’instruction CPUID. Le TSC est un compteur de cycles qui s’incrémente à une vitesse plus ou moins liée à la fréquence du processeur. Il est utile de connaître la durée en microsecondes ou nanosecondes d’un « tick » du TSC pour différents usages. Historiquement, cette durée est calculée en utilisant le Programmable Interval Timer, un composant présent dans les ordinateurs compatibles PC depuis le tout début. Ce composant n’a plus beaucoup d’autres utilités aujourd’hui, et certains chipsets ne l’implémentent plus, ou pas correctement. Ou encore, dans les machines virtuelles, l’émulation du processeur (virtualisé) n’est pas forcément exécutée de façon synchrone avec celle du timer, rendant cette mesure peu fiable. L’instruction CPUID permet de récupérer l’information de façon plus directe. Un changement similaire dans FreeBSD donne un bon aperçu de la situation.

Portages ARM, RISC-V et autres

Historiquement, Haiku est développé en premier pour les machines x86 32-bit. Une version 64 bit est apparue en 2012. D’autres versions pour les processeurs PowerPC, ARM (32 et 64 bits), RISC-V, Sparc ou encore Motorola 68000 sont dans des états d’avancement divers. Les versions ARM et RISC-V sont actuellement celles qui reçoivent le plus d’attention des développeurs. Il existe un fork de Haiku qui est entièrement fonctionnel sur certaines machines RISC-V, les changements sont intégrés petit à petit avec pas mal de nettoyage à faire.

Une des problématiques pour ces nouvelles architectures est la procédure de « bootstrap ». Pour gagner du temps et simplifier la procédure, la compilation de Haiku se base sur un certain nombre de dépendances qui sont pré-compilées depuis une machine fonctionnant sous Haiku. Cela permet de ne pas avoir à compiler des douzaines de bibliothèques tierces, avec un environnement de compilation peu contrôlé (on peut compiler Haiku depuis un système Haiku, depuis un grand nombre de distributions Linux, depuis Mac OS, depuis un BSD, ou même depuis Windows avec WSL).

Cependant, lors du développement de Haiku pour une nouvelle architecture, ces paquets précompilés ne sont bien entendu pas encore disponibles. Il est donc nécessaire d’utiliser une procédure de « bootstrap », qui va se baser sur un autre système et compiler ce qui est nécessaire en compilation croisée, pour aboutir à un système Haiku réduit au minimum de fonctionnalités, juste de quoi pouvoir lancer l’outil haikuports, qui va lui-même ensuite compiler tous les autres paquets.

Ce processus est assez complexe, et a été laissé un peu à l’abandon. Il a été récemment remis en route, avec des corrections de bugs dans l’outil haikuporter, des mises à jour dans les paquets cross-compilés (par exemple pour passer de Python 2 à Python 3), et divers autres petits problèmes. Il est maintenant à nouveau possible de construire une image disque de bootstrap au moins pour la version PowerPC.

Le portage RISC-V a reçu une mise à jour vers gcc 13 (c’était déjà le cas pour les autres architectures) et a pu être utilisé pour compiler LLVM puis Mesa (l’intégration dans la ferme de compilation de Haikuports n’est pas encore en place, donc ces compilations doivent être faites par un développeur qui lance les commandes haikuports nécessaire et patiente longtemps pendant la compilation de ces gros projets).

Les versions 68000 et PowerPC ont été un peu dépoussiérées, mais il manque toujours un certain nombre de pilotes matériels de base pour pouvoir les utiliser sur de vraies machines et même dans une certaine mesure dans QEMU (ce dernier permettant d’émuler une machine utilisant de nombreux périphériques VirtIO, ce qui pourrait simplifier un peu les choses).

La bibliothèque libroot a reçu plusieurs mises à jour dans les parties qui nécessitent du code spécifique à chaque architecture, pour ajouter en particulier le RISC-V, et au passage plusieurs autres familles de processeurs.

Une partie de Haiku qui nécessite de grosses évolutions est la gestion des bus PCI. Le pilote existant supposait la présence d’un BIOS pour effectuer la découverte du bus, ou pouvait également utiliser des tables ACPI, mais d’une façon un peu limitée, qui repose tout de même sur le BIOS ou un quelconque firmware pour assigner des adresses valides à toutes les cartes PCI. Un problème identifié depuis longtemps puisqu’il s’agit du bug numéro 3 dans l’outil de suivi de bugs de Haiku. Ce bug fêtera ses 20 ans en mars prochain, espérons qu’il soit corrigé d’ici là. Les choses avancent, puisque le pilote PCI va maintenant s’attacher correctement aux nœuds ACPI correspondants dans le device tree, ce qui permet ensuite d’interroger ACPI pour découvrir les plages d’adresses mémoires disponibles pour l’allocation d’une adresse à chaque carte PCI connectée. Du côté des nouveaux ports de Haiku, cela va également permettre d’avoir plusieurs bus PCI « racine » indépendants. Et ces développements pourraient également Être utiles pour une prise en charge complète de Thunderbolt et USB 4.

Un autre pilote qui sera utile pour les versions ARM et RISC-V est le pilote SDHCI, qui permet de s’interfacer avec les lecteurs de cartes SD ainsi que les modules eMMC. Initialement destiné uniquement aux modules connectés sur un bus PCI, le pilote a été conçu pour être facilement extensible, et permet maintenant d’utiliser également les contrôleurs SDHCI exposés via ACPI. Cependant, le pilote a encore quelques problèmes de fiabilité, et il manque une implémentation des commandes nécessaiers pour les modules eMMC, qui partagent le même protocole de communication que les cartes SD, mais utilisent un jeu de commandes différent (il y a une petite guerre de standards, le format SD s’est imposé pour les cartes amovibles, mais MMC qui n’a pas de royalties a pu prendre le marché des modules soudés sur les cartes mères, où l’interopérabilité avec le matériel existant ne pose pas autant problèmes).

Le portage sur ARM64 avance petit à petit, il parvient à démarrer une partie de l’espace utilisateur et a reçu dernièrement des corrections sur le code permettant les changements de contexte entre différents threads. L’affichage du bureau complet pour la première fois sur une machine ARM64 ne devrait donc plus être très loin.

Bootloader

Le démarrage de Haiku est pris en charge par un bootloader spécifique nommé haiku_loader. Contrairement au noyau Linux, qui peut s’initialiser tout seul quasiment dès le démarrage du matériel, le noyau de Haiku a besoin que son bootloader prépare une grande partie de l’environnement (activation de la mémoire virtuelle, initialisation de l’affichage et mise en place du « splash screen », par exemple). Le bootloader prend en charge toutes ces tâches et permet en plus de configurer des options de démarrage via un menu en mode texte, de démarrer via le réseau, d’utiliser un snapshot plus ancien du système si une mise à jour s’est mal passée.

Le bootloader a peu évolué cette année, le changement principal étant la suppression de logs de warning lors du chagement de fichiers ELF, pour les sections non traitées PT_EH_FRAME (généré par les versions modernes de gcc) ainsi que d’autres sections spécifiques aux processeurs RISC-V qui ne nécessitent pas de traitement spécifique dans ce cas.

Amélioration de performances

Beaucoup de travail a été fait sur l’amélioration des performances. C’est un sujet qui a été un peu laissé de côté au début du développement de Haiku. Le premier but était de faire fonctionner les choses, avant de les rendre plus rapides. Maintenant que les développements sont assez avancés, il est temps de commencer à étudier ce problème et à essayer de se rapprocher des perfomances d’autres systèmes.

Implémentation des IO vectorisées sur les périphériques de type bloc

Lorsqu’on veut lire ou écrire sur un disque, il faut envoyer une commande pour accéder à des secteurs consécutifs. Dans le cas normal, c'est le cache du système de fichiers qui se charge de regrouper les différents accès et de les ordonnancer de façon optimale.

Mais il y a un cas particulier pour les accès directs au disque. Par exemple, si on ouvre le disque directement (via son device dans /dev/disk/) ou encore lorsqu’un système de fichier veut écrire son journal (qui ne passe pas par le cache). Les écritures dans le journal sont faites avec des accès vectorisés (via readv ou writev) qui contiennent chacun une liste d’endroits où lire ou écrire des données. Ces accès étaient implémentés sous forme d’une boucle appelant plusieurs fois read ou write. Maintenant, la liste est directement transmise au pilote de disque qui peut ainsi mieux traiter ces accès.

Réparation du profiler

Haiku dispose d’un outil de profiling, mais celui-ci ne fonctionnait plus et retournait des données incohérentes. Plusieurs problèmes ont été corrigés pour faciliter les mesures de performances et vérifier que les optimisations rendent réellement les choses plus rapides.

Réduction des verrouillages du device manager

Le problème initial qui a conduit à ces améliorations était la lenteur du lancement de nouveaux processus. Un goulet d’étranglement qui a été identifié est le verrouillage du device_manager pour accéder au périphérique /dev/random pour initialiser le stack protector (qui a besoin d’écrire des valeurs aléatoires sur la pile). Toutes les ouvertures de fichiers dans /dev nécessitent d’acquérir un verrou qui empêche l’exécution en parallèle avec de nombreuses autres tâches liées aux périphériques matériels.

Le problème a été corrigé de deux façons : d’abord, le stack protector utilise une API permettant de générer des nombres aléatoires sans ouvrir de fichier dans /dev. D’autre part, une analyse a montré que la pile USB passait beaucoup de temps à exécuter du code en ayant verrouillé l’accès au device manager. Ce code a été modifié pour libérer le verrou plus souvent.

DT_GNU_HASH dans les fichiers ELF

Un autre aspect assez lent du lancement de processus est le chargement des bibliothèques et la recherche des symboles dans ces bibliothèques. Pour identifier si une bibliothèque contient un symbole, la recherche se fait par un hash du nom de la fonction recherchée.

Historiquement, c’est la section DT_HASH qui est utilisée, mais les utils GNU implémentent également DT_GNU_HASH, qui utilise une meilleure fonction de hash et ajoute également un bloom filter qui permet de tester très rapidement, mais de façon imparfaite, la présence d’un symbole dans une bibliothèque.

Le chargeur de bibliothèques de Haiku sait maintenant utiliser les tables DT_GNU_HASH, mais ce n’est pas encore déployé car les gains de performances ne justifient pas l’augmentation de taille des bibliothèques (il faut stocker les tables dans l’ancien et dans le nouveau format). Il sera toutefois possible de l’ajouter au cas par cas sur les bibliothèques où le gain est important (par exemple s’il y a beaucoup de symboles).

premapping de mmap

La fonction mmap permet de mapper un fichier directement en mémoire. Les écritures en mémoire sont ensuite directement enregistrées sur disque. Il n’est pas souhaitable de charger tout le fichier d’un coup au moment de l’appel à mmap, ce serait trop lent. Mais il ne fait pas non plus attendre que le logiciel accède à cette mémoire et remplir les données au goutte-à-goutte (ou plus précisément, une page de 4Kio à la fois).

Un cas particulier est le traitement des bibliothèques partagées, qui sont chargées en mémoire de cette façon. Dans ce cas, le fichier est probablement déjà chargé quelque part en mémoire pour un autre processus, et il devrait être possible de réutiliser les mêmes données. Le code testant cette possibilité ne fonctionnait pas à tous les coups, ce qui fait que des fichiers qui auraient pu être mappés tout de suite, ne l’étaient pas.

Une autre amélioration est d’utiliser plusieurs allocateurs séparés pour chaque processeur, pour réduire les blocages entre différents threads qui ont besoin de manipuler des pages de mémoire.

Suppression des zones mémoire

Les applications Haiku peuvent créer des zones de mémoires (appelées areas) qui disposent d’un identifiant unique et peuvent être partagées avec d’autres processus.

Lorsqu’une application s’arrête, il faut supprimer toutes les areas qui ont été créées. Cela était fait par une simple boucle supprimant ces zones une par une. Mais cela pose un problème: chaque suppression doit verrouiller la liste des areas puis la déverrouiller. Le code a été modifié pour verrouiller la liste une seule fois et retirer de la liste toutes les zones d’un seul coup, avant de faire les autres opérations de suppression qui n’ont pas besoin d’accéder à la liste.

Au total, toutes ces améliorations conduisent à une amélioration des performances de plus de 25% sur un test en conditions réelles (compilation d’une partie des sources de Haiku).

Calcul des sommes de contrôles des paquets réseau par le matériel

Dans un autre domaine, une perte de temps conséquente est le calcul des checksums pour les paquets réseau reçus et envoyés. En effet, ce calcul était fait systématiquement par le logiciel, même si le matériel est capable de s’en charger. Il est maintenant possible pour les pilotes réseaux qu’ils sont capables de vérifier et de générer ces checksums par eux-mêmes, et ainsi la pile réseau peut s’en dispenser. Cela permet aussi de se passer entièrement de checksums sur les interfaces localhost, qui ne devraient pas subir de corruption de paquets, et ne gagnent rien à cette vérification.

Cela a été également l’occasion de supprimer quelques copies des données des paquets réseau.

user_mutex

La structure user_mutex joue un rôle similaire aux futex de Linux. Elle est utilisée pour implémenter, par exemple, pthread_mutex et pthread_rwlock. L’implémentation avait plusieurs bugs (race conditions), et a été remplacée par un nouveau système plus efficace.

Au total, toutes ces améliorations permettent des performances 25% meilleures que la version beta 4 de Haiku. Il reste cependant de quoi faire, puisque certains benchmarks (compilation d’une partie du code source de Haiku) restent près de deux fois plus lent que l’opération équivalente sous Linux.

Chaîne de compilation

Haiku est compilé avec gcc, ld et les binutils. Ils nécessitent tout trois un petit nombre de patchs maintenus dans un dépôt git dédié et reversés dans les versions upstream autant que possible. Une version de gcc 2.95.3 est également utilisée pour les parties du système assurant encore la rétro compatibilité avec BeOS, les versions plus récentes utilisent un mangling différent et ne sont pas inter opérables.

L’outil de compilation utilisé est Jam, développé à l’origine par Perforce et dont il existe plusieurs forks dont un maintenu par Boost et un autre par Freetype. Haiku utilise sa propre version de Jam avec de nombreuses évolutions.

Commençons la liste des changements dans cette section avec des mises à jour de dépendances : Haiku est maintenant compilé avec GCC 13.2 (la version 14 sera intégrée prochainement). La bibliothèque ICU utilisée pour implémenter toutes les fonctions d’internationalisation (qui se trouve donc avoir un rôle assez important dans la bibliothèque C standard) a été mise à jour en version 74.

Le travail pour supprimer tous les avertissements du compilateur se poursuit petit à petit, mais les problèmes restants sont de plus en plus difficiles à corriger, soit parce qu’il s’agit de code tiers (qu’il est plus facile de garder en l’état pour le synchroniser avec de nouvelles versions), soit parce que l’avertissement ne peut pas être corrigé proprement sans perte de performance, ou encore d’une façon qui contente à la fois gcc 13 et gcc 2 pour les parties du code compilées avec ces deux versions.

On peut toutefois mentionner que tous les trigraphes présents dans le code (par accident, par exemple il est facile d’écrire « ??! » dans un commentaire) ont été supprimés. Ils ne sont plus disponibles dans C++ à partir de la version 17 et génèrent des erreurs de compilation.

D’autre part, l’option de compilation -Wno-error=deprecated a pu être désactivée, car plus aucun code ne déclenche cette erreur.

Puisqu’on parle d’options de compilation : l’optimisation « autovectorisation » pour la compilation du noyau a été désactivée pour l’instant. Cette option fait que le code utilise des instructions SSE, et faire cela dans le noyau problématique pour la plupart des machines virtuelles (QEMU, VMWare et Virtual Box). La plupart des autres noyaux n’utilisent pas ces instructions, ce qui fait que des bugs dans les hyperviseurs sont tout à fait possibles, par manque de tests. Mais le problème pourrait aussi venir de Haiku. L’investigation est, pour l’instant, remise à plus tard.

Un dernier changement dans le système de build consiste à permettre l’utilisation de git worktree. Quelques commandes git sont utilisées lors de la compilation pour calculer le numéro de version du code en train d’être compilé, et ça ne fonctionnait pas correctement dans ce cas de figure.