Sommaire
Applications
Tracker
Tracker est le navigateur de fichiers de Haiku. Le code est hérité directement de BeOS (cette partie avait été publiée sous licence libre lors de l’abandon de BeOS par Be) et fait l’objet depuis de nombreuses années d’un gros travail de nettoyage et de modernisation.
Pas de grosses nouveautés ces derniers mois, mais des corrections pour plusieurs régressions suites à du nettoyage effectué précédemment. Par exemple, les icônes des disques montés sont à nouveaux affichés sur le bureau dans les dialogues d’ouverture et d’enregistrement de fichiers. L’annulation du filtrage du contenu d’un dossier en tapant un nom de fichier partiel est correctement annulé si on appuie sur échap.
Enfin, des problèmes de synchronisation de l’icône de la poubelle, qui apparaissait pleine alors qu’elle était vide, ont été corrigés. Ces problèmes étaient déjà présents dans BeOS.
Terminal
Le terminal permet de lancer des applications en ligne de commande.
Un chantier en cours consiste à rendre le terminal utilisable comme un “replicant”, c’est-à-dire de pouvoir l’intégrer dans d’autres applications telles que l’IDE Genio. Cette approche demande de restructurer beaucoup de choses, et pour l’instant, il est plus simple pour les développeurs de Genio de recopier une partie des sources du Terminal dans leur projet et de les intégrer de façon plus statique. Les problèmes sont corrigés petit à petit.
Une autre correction mérite d’être mentionnée: le terminal se plaçait lui-même dans le dossier de travail du shell lancé lors de l’ouverture d’un nouvel onglet. Si ce dossier se trouve dans un disque qu’on essaie par la suite de démonter, le démontage échoue (même si l’application lancée dans le terminal a elle-même changé de dossier entretemps). Désormais le terminal ne modifie pas son dossier actif et ne bloque plus le démontage des disques.
Mail
L’application Mail permet de lire et d’envoyer du courrier électronique. Elle est composée d’un serveur de synchronisation et d’une interface graphique indépendante. Entre les deux, les mails sont stockés sous forme de fichiers augmentés d’attributs étendus, ce qui permet d’utiliser Tracker et les requêtes BFS comme outil principal pour traiter les messages.
Les changements listés ici concernent l’application de lecture et rédaction de messages:
HaikuDepot
HaikuDepot est à la fois le gestionnaire de paquets et le magasin d’applications de Haiku. Ce double rôle conduit pour l’instant à une interface qui prête un peu à confusion, et l’interface devrait être repensée pour un fonctionnement plus intuitif. En attendant, quelques petites améliorations ont tout de même été faites pour rendre les problèmes moins gênants.
Lorsqu’une recherche dans la vue « paquets mis en avant » ne donne aucun résultat, il y a affichage d’un lien permettant de poursuivre la recherche dans la liste complète des paquets. En effet, de nombreux utilisateurs se sont plaints de ne pas trouver certains logiciels en effectuant une recherche, sans se rendre compte qu’ils faisaient une recherche dans une liste de quelques dizaines de paquets et pas dans tout ce qui est disponible.
TextSearch
TextSearch est un outil de recherche dans le contenu des fichiers par expressions régulières (une version graphique de grep
).
Il reçoit ce trimestre une fonction pour filtrer les fichiers à rechercher, équivalent à l’option grep --include
.
Debug Analyzer
Debug Analyzer est un outil de profiling et d’analyse de traces d’exécution.
Correction d’un problème de compilation suite à des changements dans l’API de BObjectList (cet outil n’est pas compilé par défaut, il avait donc été oublié lors du changement d’API au trimestre précédent).
Préférences d’apparence
Dans la configuration des couleurs du système, renommage de la couleur « barre d’état » en « barre de progression ». Le nom « barre d’état » (status bar en anglais) correspond à la classe BStatusBar
utilisée par BeOS et Haiku, mais tout le monde appelle ça une barre de progression. On peut au moins éviter la confusion pour les utilisateurs, à défaut de pouvoir le faire pour les développeurs d’applications en renommant la classe elle-même (ce qui causerait des problèmes de compatibilité d’API et d’ABI).
Utilisation de IconMenuItem
Ce changement concerne l’application ShowImage (visualiseur d’images) ainsi que FileTypes (les préférences d’association de types fichiers avec des applications). Ces deux applications utilisent un menu pour sélectionner une application (pour ouvrir une image dans un éditeur, ou pour associer un type de fichier à une application, respectivement).
Les applications pour Haiku utilisant des icônes colorées et facilement identifiables, c’est beaucoup mieux qu’une liste de noms pour s’y retrouver rapidement. Ces deux applications utilisent donc maintenant des IconMenuItem dans ces menus, pour afficher les applications avec leur icône respective.
Adaptation aux écrans à très haute réolution
Un travail en cours sur les applications concerne l’adaptation aux écrans à très haute résolution.
Presque toutes les applications pour Haiku utilisent un système de mise en page dynamique, et toutes les ressources (police de caractères, icônes…) sont vectorielles. Cela permet en théorie d’afficher l’interface avec un niveau de zoom arbitraire. Cependant, une partie du code a été écrit avec des tailles en pixels « en dur » et ne s’adapte pas comme il faudrait (la bonne façon de faire est de se baser par exemple sur la taille de la police de caractères sélectionnée par l’utilisateur).
Ce trimestre, on trouve des évolutions à ce sujet dans plusieurs applications:
- Expander (décompression d’archives)
- SerialConnect (communication par port série)
- Mise à l’échelle de la barre de défilement
- Préférences d’imprimantes
- Mise à l’échelle des icônes
Outils en ligne de commande
Remote Desktop
L’outil de connexion au bureau à distance n’est pas vraiment une application en ligne de commande. Cependant, il nécessite pour l’instant un lancement depuis un terminal avec les bonnes options, et selon les cas, la mise en place d’un tunnel SSH. Une interface grapique plus simple d’uitlisation sera probablement ajoutée plus tard.
- Amélioration du parsing de la ligne de commande et en particulier de l’option pour choisir un port SSH
- Activation de l’option SO_REUSEADDR permettant de plus facilement relancer l’outil s’il plante, sans attendre un timeout de la connexion précédente qui n’a pas été fermée proprement
Time
Le panneau de préférences de date et heure peut être lancé en ligne de commande avec une option spécifique pour forcer une synchronisation NTP. Cette fonctionnalité n’est pas vraiment documentée, à l’origine il s’agit plutôt d’une astuce interne au système. L’application reconnaît maintenant l’option --help
standardisée et affiche un message d’aide qui documente cette fonctionnalité.
Il peut être utile de relancer cette commande manuellement si jamais la synchronisation au démarrage n’a pas fonctionné (par exemple si le réseau n’était pas disponible à ce moment-là). En particulier, cela peut être utilisé dans des scripts d’automatisation et pour des machines où l’interface graphique n’est pas facilement accessible (serveurs de build par exemple).
pkgman
pkgman
est une commande permettant d’installer, mettre à jour et rechercher des paquets logiciels.
Ajout d’une option --no-refresh
pour ne pas retélécharger la base de données des paquets.
Cette base de données contient non seulement les noms des paquets, mais aussi leur description courte et la liste des “provides” (par exemple: commandes et bibliothèques fournies par chaque paquet). pkgman vérifié déjà si une nouvelle version de la base de données est disponible, mais cette dernière peut être mise à jour plusieurs fois par jour par l’intégration continue.
Le nombre de paquets augmentant, la taille de la base de données devient non négligeable (plusieurs méga-octets), ce qui pose problème en particulier pour les utilisateurs et développeurs ne disposant pas d’un accès internet illimité.
su
La commande su
est peu utilisée puisque l’utilisateur par défaut a déjà tous les droits. Son implémentation était donc un peu incomplète. Elle peut toutefois être utile pour avoir des utilisateurs supplémentaires restraints, par exemple pour un accès à distance par ssh.
- La commande
su
ne demande pas de mot de passe si l’utilisateur dispose déjà de l’accès root
- Toutes les commandes liées à la gestion des utilisateurs (su, login…) configurent les groupes actifs lors du changement d’utilisateur
listarea
listarea est une commande de debug permettant de lister les zones mémoire allouées à différentes applications. Elle affiche maintenant le verrouillage et les protections de ces zones (swappable ou non, exécutabele ou non, accessible en écriture ou non).
fdinfo
fdinfo permet d’examiner les descripteurs de fichiers ouverts (un peu comme lsof
). Cette commande peut maintenant afficher en plus le dossier courant de chaque application (ce qui aurait été bien utile pour identifier le problème avec le dossier courant du Terminal ci-dessus).
install-wifi-firmwares
Ce script permet d’installer les firmwares pour certaines très anciennes cartes Wifi. Les firmwares publiés à l’époque sont disponibles avec des licenses n’autorisant pas la redistribution ou les modifications de packaging, ce qui empêche l’intégration dans le système de paquets habituel. Le problème a été corrigé depuis longtemps par les fabricants de cartes Wifi, mais les anciens firmwares n’ont jamais été republiés avec des licenses mises à jour.
Le script a été mis à jour pour récupérer certains firmwares depuis un nouveau serveur, l’ancien emplacement utilisé n’étant plus disponible.
Kits
La bibliothèque de fonctions de Haiku est découpée en kits qui regroupent des ensembles de fonctions et de classes par thématique (stockage sur disque, interface graphique…). Dans certains cas il s’agit principalement d’une méthode d’organisation du code source et de la documentation (les kits pouvent être très interdépendants). Certains kits sont toutefois fournis sous forme de bibliothèques séparées.
Support kit
Ce kit contient diverses fonctions utilitaires et basiques du système.
Changement d’API pour la classe BUrl. Dans l’ancienne version de cette classe, il était possible de construire un objet BUrl représentant une URL encodée ou non-encodée (échappement des caractères réservés). Cela rendait trop facile d’oublier d’encoder une URL avant de l’utiliser, ou bien d’encoder plusieurs fois une URL et de se retrouver avec un lien invalide.
La nouvelle API impose d’indiquer dès la création d’un objet BUrl si la chaîne de caractères servant de base est déjà encodée ou non. L’objet BUrl construit représentera toujours une URL déjà encodée, qui peut éventuellement être décodée pour affichage si nécessaire.
Interface kit
Ce kit contient tout ce qui se rapporte à l’interface graphique: fenêtres, vues, contrôles, mise en page…
Retour en arrière sur une modification des raccourcis claviers de BTextView pour naviguer vers les mots suivant et précédent. Les nouveaux raccourcis entrent en conflit avec des raccourcis déjà utilisés par plusieurs applications, et n’apportaient pas grand-chose.
Correction de problèmes de compatibilité dans le format des données stockées par la classe BPicture
(il s’agit d’un enregistrement de commandes envoyées au serveur graphique, qui peuvent être rejouées plus tard). Le format des données stockées était différent de celui de BeOS. Certaines applications utilisant un objet BPicture
enregistré dans une ressource de l’application, ne s’affichaient pas correctement.
Amélioration de la gestion des sous-menus, en particulier cela corrige un crash si un sous-menu est fermé en utilisant la touche échap.
Remise à plat de tous les calculs accumulés au cours des années pour générer les couleurs de l’interface graphique en fonction des couleurs choisies par l’utilisateur. Chaque morceau de code concernait faisait ses propres calculs pour générer de jolis dégradés, des variantes plus sombres et plus claires, etc. Cela fonctionnait bien avec le thème par défaut, mais pas forcément avec des choix de couleurs qui en sont très éloignés. Le nouveau code est plus simple, plus prédictible, et permet de rassembler ces calculs dans la classe « control look », qui peut être remplacée par un add-on pour fournir une apparence complètement différente.
Cela peut nécessiter d’ajuster un peu les couleurs dans les préférences d’apparence si vous les avez personnalisées.
Storage kit
Ce kit regroupe tout ce qui concerne le stockage de masse et la gestion des fichiers.
Harmonisation de la nouvelle fonction BQuery::SetFlags
avec d’autres fonctions similaires, et ajout d’une page de documentation pour cette fonction.
Correction d’un crash lorsqu’on enregistre un type MIME alors que le type parent n’existe pas (par exemple si on enregistre image/gif alors que le type image n’existe pas).
Ajout d’une constante pour identifier les systèmes de fichiers FAT16 parmi la liste des systèmes de fichiers connus.
Shared kit
Le shared kit contient des fonctions expérimentales en cours de développement mais déjà utilisées par plusieurs applications.
Contrairement aux autres kits, il est fourni sous forme d’une bibliothèque statique, ainsi chaque application peut en utiliser une version différente (choisie au moment de la compilation) et il n’y a pas de contraintes pour conserver une stabilité d’API ou d’ABI. Les fonctions développées dans le shared kit peuvent ensuite être migrées vers les autres kits une fois qu’elles sont finalisées.
La classe « color list » (utilisée par exemple dans les préférences d’apparence) accepte maintenant le glisser-déposer de couleurs.
Serveurs
Les serveurs sont des applications lancées au démarrage du système. Ils sont similaires aux services systemd. Ils fournissent des services utiles à l’implémentation de la bibliothèque standard, car tout ne peut pas être fait dans une bibliothèque partagée.
app_server
app_server
regroupe le serveur graphique de Haiku (utilisé au travers de l’interface kit) ainsi que la gestion des applications en lien avec l’application kit.
Correction d’un problème d’initialisation de variables indiquant dans quels workspaces (bureaux virtuels) une fenêtre doit être présente. Cela se manifestait par l’apparition de morceaux incomplets de la fenêtre si on change de bureau virtuel pendant son apparition. Le bug existait depuis 15 ans mais n’avait jusque-là pas pu être identifié.
Les curseurs de souris ne sont plus générés en bitmap à la compilation à partir des sources vectorielles. C’est maintenant fait lors de l’initialisation du serveur graphique, ce qui permet d’avoir un plus gros curseur sur les écrans à très haute résolution.
input_server
input_server
se charge des périphériques d’entrée utilisateurs (claviers, souris et autres périphériques de saisie et de pointage).
Correction de la keymap espagnole latino-américaine dans laquelle plusieurs combinaisons de touches ne fonctionnaient pas comme sur les autres systèmes.
Pilotes
ACPI, gestion d’énergie, système
Mise à jour de ACPICA pour la prise en charge de ACPI avec la dernière version disponible.
Correction de problèmes dans le pilote poke
(permettant l’accès direct à la mémoire pour écrire certains pilotes en espace utilisateur) pour mieux valider les paramètres des ioctl
et éviter de pouvoir facilement déclencher un kernel panic suite à une mauvaise utilisation du pilote.
Réseau
Correction d’un problème dans la pile TCP ou les retransmissions de paquets lors de l’établissement de la connexion n’étaient pas faits, si le premier paquet était perdu, la connexion ne s’établissait jamais.
Lorsque IP_HDRINCL
est activé (une application demande à envoyer et recevoir elle-même les en-têtes IP des paquets reçus), la pile réseau s’assure tout de même que les en-têtes générés ont bien un checksum valide. Cela permet à traceroute
de fonctionner correctement par exemple.
Mise en place de l’infrastructure pour la découverte de MTU deu chemin. Cela permet de déterminer la taille maximale des paquets qu’on peut envoyer vers un serveur, sans que de la fragmentation IP soit mise en jeu en cours de route (ce qui, au mieux dégraderait les performances, au pire empêcherait la connexion de fonctionner correctement):
- Ajout de l’option
IP_DONTFRAG
pour demander aux routeurs de ne pas redécouper certains paquets,
- Remontée de l’information ICMP
FRAGMENTATION_NEEDED
pour détecter qu’on a essayé d’envoyer un paquet trop gros.
Cela permet déjà de détecter les problèmes de MTU, mais pas encore de les corriger automatiquement. La suite du code est encore en cours de test.
Remplacement du pilote iprowifi3945 par la version mise à jour disponible dans OpenBSD (pilote “wpi”) à la place de celle de FreeBSD qui est actuellement moins bien maintenue.
Interface homme-machine
Ajout de la tablette Intuos 4 dans le pilote pour les tablettes Wacom, ainsi que du support de la molette présente sur certaines tablettes.
Systèmes de fichiers
NFS4
NFS est un système de fichier en réseau. Une machine serveur se charge réellement du stockage des fichiers, et d’autres machines peuvent monter ce disque et accéder aux fichiers partagés. Plusieurs machines peuvent accéder au même serveur en même temps et modifier les fichiers, ce qui nécessite une attention particulière lors de l’implémentation d’un système de fichier client.
Le travail sur le pilote NFSv4 se poursuit pour le stabiliser et améliorer sa compatibilité avec les serveurs NFS existants.
Correction de problèmes de gestion du cache et de libération anticipée d’inodes`, points sur lesquels NFS est un peu inhabituel par rapport à d’autres systèmes de fichiers puisque des évènements peuvent arriver du serveur NFS concernant un fichier qui a été supprimé localement, par exemple.
Correction d’un problème qui pouvait conduire un fichier nouvellement redimensionné à contenir des données non initialisées au lieu d’octets à 0.
Cela permet de corriger des problèmes détectés par des tests NFSv4 existants pour d’autres systèmes.
EXT4
Le pilote ext4 permet de monter, en lecture et en écriture, les systèmes de fichiers ext2, ext3 et ext4 développés pour Linux.
Implémentation et activation de la fonctionnalité « metadata_csum_seed » qui est activée par défaut pour les systèmes de fichiers nouvellement créés sous Linux.
Corrections dans le « tree splitting » qui n’était pas implémenté correctement, empêchant d’accéder à des dossiers contenant un trop grand nombre de fichiers.
RAMFS
RAMFS est un système de fichiers non persistant, stockant les fichiers uniquement dans la RAM. Il est plus rapide qu’un système de fichier traditionnel.
Correction de crashs lors de la création de gros fichiers et lors du remplacement d’un hardlink par un autre fichier.
FAT
FAT est un système de fichiers développé par Microsoft pour DOS et les anciennes versions de Windows. Il est assez répandu et sert un peu de format d’échange standard en particulier pour les supports de stockage externes (clés USB, cartes SD, disquettes…).
Ajout d’assertions et de vérifications d’intégrité supplémentaires. Le pilote FAT utilisé actuellement provient de FreeBSD, dont les développeurs nous ont assuré qu’il était bien testé et maintenu. Mais, de façon similaire aux pilotes Wifi, on se rend compte que les bases d’utilisateurs de Haiku et de BSD ne sont pas du tout les mêmes, et nous sommes face à beaucoup de systèmes de fichiers FAT corrompus ou inhabituels, ce qui se produit peut-être moins souvent dans les utilisations de FreeBSD sur un serveur par exemple.
libroot
La libroot contient l’équivalent de la libc, libdl, libpthread et libm d’un système UNIX standard, ainsi que des fonctions bas niveau spécifiques à BeOS.
Les extensions GNU et BSD sont déportées dans des bibliothèques séparées (libgnu et libbsd), ce qui permet de respecter au mieux la spécification POSIX sans avoir à utiliser des astuces telles que des « weak symbols ».
Mise à jour de la libio
La bibliothèque standard de Haiku est à l’origine un fork de la glibc, utilisant exactement la même version que BeOS afin de garantir une compatibilité d’ABI optimale avec ce dernier. Cependant, cette version ancienne et obsolète ne répond pas aux besoins des applications modernes.
Petit à petit, des parties de la bibliothèque C sont donc remplacées par des composants venant de FreeBSD, NetBSD, OpenBSD ou plus récemment de musl. Certaines choses sont très bien standardisées et ne posent pas de problèmes, pour d’autres parties, des symboles internes de la bibliothèque sont exposés et parfois exploités par des applications (directement par des développeurs applicatifs pour contourner un bug, ou alors parce que les développeurs de la glibc ont mal isolé les choses et ont exposé des détails internes).
Ce trimestre, la partie libio (gestion des flux d’entrée-sortie) a été mise à jour avec la dernière version de la glibc. Il n’est pas possible d’utiliser une autre bibliothèque C pour cette partie sans casser l’ABI, mais la mise à jour est possible.
Correction de multiples problèmes dans les fonctions standard C et les extensions BSD:
Ajout d’une vérification de la locale passée à setlocale
pour retourner une erreur si la locale demandée est invalide.
L’ouverture d’un chemin se finissant par un / avec open()
échoue si le fichier n’est pas un dossier (par exemple open("/home/user/foo.txt/")
).
Validation du paramètre “how” de la fonction shutdown()
et retour d’une erreur si le paramètre n’est pas une valeur connue.
Les queues d’évènement créées par kqueue
ne sont pas conservées lors d’un fork
(même comportement que les BSD).
Un socket sur lequel il n’y a jamais eu d’appel à listen()
ou connect()
ne doit pas déclencher les erreurs EPIPE
ni ENOTCONN
.
La fonction socket()
retourne maintenant les bons codes d’erreurs détaillés si elle ne peut pas créer le socket: EPROTOTYPE
si le type de protocole est inconnu, EPROTONOSUPPORT
s’il est connu mais pas disponible, EAFNOSUPPORT
si la famille d’adresse n’est pas disponible. Auparavant, tous ces cas renvoyaient EAFNOSUPPORT
.
Amélioration de la gestion des erreurs dans accept()
Gestion de cas particuliers pour bind()
en UDP
Ajout de l’option RTLD_GROUP
pour dlopen()
. Il s’agit d’une extension développée par Solaris qui permet d’avoir plusieurs espaces de noms pour la résolution de symboles lors du chargement de bibliothèques partagées. En particulier, dosemu l’utilise pour fournir aux programmes DOS une bibliothèque C indépendante de celle de l’hôte (fournissant donc des fonctions memcpy, memset… qui entreraient en conflit avec celles de l’hôte). L’implémentation est triviale, car le même comportement était déjà en place pour la gestion des add-ons de BeOS; il n’était simplement pas accessible au travers de l’API POSIX dlopen()
. Linux implémente ce flag sous un autre nom, cependant, la documentation de la glibc n’est pas correcte, et FreeBSD a implémenté ce qui est documenté pour la glibc avec le même nom. C’est pourquoi le nom utilisé par Solaris, qui n’est pas ambigu, est utilisé pour l’instant, en espérant que la méprise entre Linux et FreeBSD pourra être corrigée.
sethostname()
retourne une erreur si le hostname proposé est trop long (auparavant il était simplement tronqué).
Intégration des changements de POSIX-2024
La spécification POSIX a été mise à jour en 2024. Cette mise à jour est assez importante grâce à un changement de la méthode de travail de l’Austin Group qui maintient la spéficication. Le groupe de travail a ouvert un bug tracker sur lequel il est possible de remonter des problèmes et de proposer des améliorations (à conditions que ces dernières soient déjà implémentées sous forme d’extensions sur un assez grand nombre de systèmes).
Cela a permis à plus de monde de prendre part à la spécification et de standardiser beaucoup de nouvelles choses. Haiku intègre ces changements petits à petits, parfois par anticipation, parfois parce que l’extension correspondante était déjà disponible, et parfois parce que le portage d’un logiciel le nécessite.
- Ajout de
O_CLOFORK
, MSG_CMSG_CLOEXEC
, et MSG_CMSG_CLOFORK
pour fermer des descripteurs de fichiers lors d’un fork (équivalent de O_CLOEXEC
qui ferme lors d’un exec, typiquement après un fork). Au passage, ajout dans la libbsd de closefrom()
et closerange()
, ces deux fonctions permettant de lancer des tests développés pour BSD pour ces nouveaux drapeaux.
- Ajout de
fdatasync()
, une fonction qui s’assure que le contenu d’un fichier est bien enregistré sur disque et pas seulement dans le cache.
Améliorations sur la gestion de la mémoire
La gestion de la mémoire est un sujet central pour un système POSIX. L’API proposée (malloc
, realloc
, calloc
et free
) est à la fois très simple d’utilisation et très générique. Elle a donc tendance à être très sollicitée par les applications, ce qui en fait un composant critique de l’optilisation des performances du système. De plus, les applications sont de plus en plus consommatrices de mémoire et le matériel a tendance à en contenir de plus en plus.
L’allocateur mémoire a été remplacé il y a quelques mois, l’ancien allocateur hoard2 ne permettant pas d’agrandir dynamiquement l’espace alloué à une application. Après plusieurs essais, c’est pour l’instant l’allocateur d’OpenBSD qui a été retenu. En effet, beaucoup d’allocateurs plus modernes supposent un espace d’adressage 64 bit et sont peu économes en termes de réservation d’espace mémoire.
Cependant, même l’allocateur d’OpenBSD montrait ses limites sur les systèmes 32 bit. Son paramétrage a été amélioré, et d’autres modifications ont également été faites pour réduire la fragmentation de l’espace mémoire. Cela corrige des problèmes ou GCC ne parvient pas à allouer assez de mémoire lors de la compilation de très gros fichiers (par exemple lors de la compilation de clang ou de webkit). Il reste recommandé de désactiver l’ASLR (randomization de l’espace d’adressage) dans les cas où on a besoin de beaucoup de mémoire pour une application 32 bits.
Noyau
Le noyau de Haiku est un noyau monolithique tout à fait classique pour un système UNIX. Il permet le chargement dynamique de modules, et fournit une API relativement stable pour ces derniers, ce qui permet de maintenir des pilotes facilement en dehors du dépôt de sources de Haiku.
Correction de problèmes causant le kernel panic « failed to acquire spinlock for a long time » lorsque l’affichage à l’écran des logs du noyau est activé.
Ajout d’assertions supplémentaires dans le code de gestion de la mémoire virtuelle pour essayer de détecter des problèmes au plus tôt et avant de risquer de corrompre des données importantes.
Correction de l’affichage des paramètres des appels systèmes dans strace
sur x86.
Correction de problèmes dans la gestion des permissions pour write_stat
(modification des informations sur un fichier comme la date de modification) dans le noyau ainsi que dans les systèmes de fichiers RAMFS, BFS et EXT4. Cela corrige des comportements étranges observés lors de l’utilisation de rsync
.
Ajout d’un test vérifiant le bon fonctionnement des exceptions remontées par le FPU lors de calculs en virgule flottante (ces exceptions sont un peu difficiles à traiter dans un système multitâche, et en particulier dans Haiku où le code du noyau peut lui-même utiliser le FPU alors que ce n’est pas le cas pour d’autres systèmes).
Correction de problèmes liés au découpage et au redimensionnement des areas
(zones de mémoires allouées par les APIs prévues à cet effet de BeOS, ou indirectement par mmap et d’autres fonctions permettant de manipuler l’espace mémoire). Cela corrige des problèmes pour RAMFS ainsi qu’un kernel panic observé lors du lancement de dosemu.
Correction de problèmes avec les areas
en lecture seule, qui pouvaient aboutir dans certains cas à une sous-évaluation de la mémoire utilisée, aboutissant à un kernel panic, car il n’y a plus de mémoire disponible à un moment où le noyau ne s’y attend pas. Cela a été mis en évidence en particulier avec l’utilisation mémoire de certains navigateurs web, qui ont tendance à gérer la mémoire directement sans passer par l’allocateur standard du système, pour des raisons de performance.
Remise en route de guarded_heap
(un allocateur mémoire qui détecte les dépassements de buffers, au prix d’une consommation mémoire fortement augmentée). Correction de problèmes mis en évidence par cet allocateur dans quelques pilotes.
Dans la structure mcontext/ucontext passée aux fonctions de traitement de signaux, ajout de plusieurs registres manquants (registres de segments, addresse de faute…). Cela est utilisé par le JIT de dosemu et va probablement permettre d’utiliser le JIT dans d’autres applications également. En effet, une approche possible pour le JIT est de déclencher volontairement un signal, afin d’intercepter l’état des registres, éventuellement de le manipuler, puis de reprendre l’exécution là où elle s’était arrêtée.
Ajout de vérification de permissions manquantes dans l’appel système get_extended_team_info
.
Correction d’une possible fuite d’un descripteur de fichier dans le VFS.
Bootloader
Mise à 0 de tous les registres non utilisés lors de l’appel de fonctions du BIOS, afin d’aider à investiguer des problèmes avec certains BIOS capricieux.
Amélioration des messages d’erreurs lorsque le bootloader ne parvient pas à charger le fichier ELF du noyau. Le chargeur de fichiers ELF du noyau est volontairement incomplet pour simplifier les choses (après tout, il a besoin seulement de charger le noyau), mais cela pose problème lors de mises à jour de GCC ou lors du portage sur de nouvelles architectures, si l’organisation du fichier ELF du noyau se trouve modifiée.
Correction de problèmes de compilation lorsque des logs de debug optionels sont activés.
Documentation
La documentation de Haiku se découpe principalement en trois parties:
- Un guide de l’utilisateur,
- Une documentation d’API pour les développeurs d’applications,
- Une documentation d’implémentation pour les développeurs du système lui-même.
API (Haiku book)
Documentation de la classe BControl
(classe abstraite qui fournit l’API standard de la plupart des contrôles utilisables dans l’interface graphique, les rendant interchangeables dans une certaine mesure).
Documentation de AdoptSystemColors
et HasSystemColors
pour la classe BButton
.
Ajout de documentation pour les extensions à dlfcn.h
par rapport à ce qui est déjà spécifié par POSIX.
Environnement de compilation
Haiku est écrit en C++ et utilise jam
(un concurrent de make
) comme outil principal de compilation. Cet outil a été retenu, car il permet de définir des règles de compilation génériques et réutilisables pour faire toutes sortes de choses. La compilation de Haiku pouvant mettre en jeu trois compilateurs différents (un pour le système hôte, un pour le système Haiku cible, et un troisième pour la couche de compatibilité avec BeOS), la plupart des autres outils ne répondent pas bien aux besoins.
Suppression de règles Jam redondantes. Jam repose sur des règles nommées pour savoir quelles actions sont nécessaires pour générer une cible à partir de sources. Les règles “Application”, “Server”, “Preferences” et “Executable” étaient toutes identiques, elles ont donc toutes été remplacées par “Application” pour simplifier le système de build.
Correction de “warnings” du compilateur pour des variables inutilisées et suppression de code mort (dans le cadre du maintien d’un code propre et lisible, une tâche plus ou moins continue pour suivre l’évolution des bonnes pratiques, la disponibilité de nouveaux outils d’analyse, et absorber la dette technique qui peut s’accumuler au cours d’un projet aussi ancien).
Début de support pour GCC 15: il est ajouté dans la liste des versions du compilateur reconnues pour le système hôte, ce qui permet de compiler Haiku depuis un système Linux très récent. L’intégration en tant que compilateur cible viendra plus tard.
Remplacement de la commande which
utilisée dans certains scripts de build par l’équivalent command -v
, ce qui évite une dépendance à une commande non standard qui n’est pas forcément installée par défaut partout.
Dans le makefile engine (un template de makefile proposé pour développer facilement des applications pour Haiku), ajout de documentation et d’exemples pour les variables INSTALL_DIR
et TARGET_DIR
.
Portage de Haiku sur d’autres CPUs
RISC-V
Correction d’un problème dans un script de link qui empêchait le démarrage du noyau.
Mise à jour de paquets utilisés pour compiler le système de base.
Mise en place d’un serveur de compilation de paquets pour RISC-V, ce qui permet de remplir le dépôt de paquets pour cette architecture et d’envisager une version officielle de Haiku pour RISC-V lors de la prochaine version bêta. L’architecture RISC-V s’ajoutera ainsi au x86 (32 et 64 bit) déjà supporté.