❌

Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraĂźchir la page.
À partir d’avant-hierFlux principal

Haiku a 23 ans et un quart

La derniĂšre dĂ©pĂȘche annuelle sur les nouveautĂ©s dans Haiku a dĂ©passĂ© la longueur maximale tolĂ©rĂ©e par Linuxfr (et Ă©tĂ© finalement dĂ©coupĂ©e en plusieurs parties publiĂ©es sĂ©parĂ©ment). Aussi, les nouveautĂ©s sur Haiku seront dĂ©sormais publiĂ©es trimestriellement, pour faire face Ă  l’augmentation d’activitĂ© dans le projet.

Sommaire

Ce rapport est basĂ© sur les rapports mensuels d’activitĂ© d’aoĂ»t, septembre et octobre publiĂ©s sur le site de Haiku. Il couvre les changements de code survenus entre hrev57901 et hrev58291 de Haiku.

Certains des changements mentionnĂ©s dans ce rapport font partie des derniers dĂ©veloppements du mois d'aoĂ»t, et Ă©taient dĂ©jĂ  prĂ©sents dans la version R1 bĂȘta 5 qui a Ă©tĂ© publiĂ©e dĂ©but septembre 2024.

Les corrections de bugs sont appliquĂ©es sur la branche bĂȘta 5 si elle est concernĂ©e, mais les nouveaux dĂ©veloppements sont mis dans la branche principale et seront disponibles uniquement dans les « nighlty builds Â» (constructions journaliĂšres) puis dans la prochaine version, qui sera probablement Ă©tiquetĂ©e R1 bĂȘta 6.

La version R1 est trĂšs attendue, mais la feuille de route comporte toujours environ 600 bugs et demandes d’amĂ©lioration. Jusqu’à ce qu’ils soient tous traitĂ©s (corrigĂ©s, devenus obsolĂštes ou dĂ©placĂ©s vers une version plus tardive), Haiku continue de publier des versions bĂȘta.

Applications

Amélioration et corrections de textes de messages dans diverses applications (humdinger).

L’application Switcher — permettant de naviguer rapidement entre les diffĂ©rentes fenĂȘtres et applications Ă  l’aide d’un menu qui apparaĂźt lorsque la souris se trouve sur les bords de l’écran — peut Ă  nouveau ĂȘtre compilĂ©e. Cette application n’est pas terminĂ©e et non intĂ©grĂ©e dans Haiku par dĂ©faut pour l’instant (nephele).

Dans les préférences de disposition clavier, des icÎnes avaient disparu de certains menus suite à un problÚme dans une modification précédente. Ces icÎnes sont maintenant de retour (jscipione).

Les rĂ©glages de polices de caractĂšres de WebPositive peuvent faire des retours Ă  la ligne dans le texte d’exemple utilisĂ© pour visualiser la police choisie (correction rĂ©cupĂ©rĂ©e depuis la fenĂȘtre de rĂ©glage des polices du systĂšme, qui utilise une variante du mĂȘme code). (nipos).

Le raccourci clavier « muet » permet d’alterner entre l’activation et la dĂ©sactivation du son, au lieu de toujours passer en mode muet (korli).

Plusieurs applications pouvaient ouvrir leurs fenĂȘtres en dehors de l’écran si leur derniĂšre position enregistrĂ©e n’était pas bonne (aprĂšs un changement de rĂ©solution d’écran par exemple). L’appel de la fonction MoveOnScreen() aprĂšs la crĂ©ation d’une fenĂȘtre permet de rĂ©gler ce problĂšme (korli, pinaraf, waddlesplash).

Icon-O-Matic ouvre ses dialogues de sĂ©lection de fichiers dans le dossier oĂč se trouve l’icĂŽne en cours d’édition (nipos).

Il est possible de sélectionner une famille de polices directement dans FontDemo (nipos).

Améliorations du mode sombre

Modifications faites par nipos et nephele.

Depuis la version bĂȘta 5 de Haiku, il est beaucoup plus simple de configurer un thĂšme de couleurs dans Haiku (avec seulement 3 couleurs Ă  sĂ©lectionner, les autres Ă©tant calculĂ©es automatiquement).

Cependant, toutes les applications et contrĂŽles graphiques ne se comportent pas forcĂ©ment trĂšs bien, en particulier si on choisit une couleur de fond de fenĂȘtres sombre. Ce trimestre, on trouve donc des amĂ©liorations sur ColumnListView (contrĂŽle permettant l’affichage de donnĂ©es en listes, en arbre et en colonnes), et dans les applications Debugger, Mail (en particulier les marqueurs de portions de message citĂ©es), WebPositive, ResEdit, FontDemo, Cortex, Sudoku et Tracker (les fenĂȘtres de configuration des permissions de fichiers et de statut de copie de fichiers), ainsi que dans les prĂ©fĂ©rences de disposition clavier (couleur des touches de clavier affichĂ©es), et de configuration des Ă©crans et des Ă©crans de veille. Ces applications utilisaient encore quelques couleurs codĂ©es « en dur Â» qui ne s’adaptaient pas automatiquement au thĂšme choisi.

En outre, les formules de calcul utilisées pour générer le thÚme de couleurs ont été améliorées pour donner de meilleurs résultats dans le cas de couleurs sombres, assurant de conserver un bon contraste entre tous les éléments graphiques et une meilleure cohérence des couleurs.

AboutSystem

L’application AboutSystem donne quelques informations sur la machine (RAM, CPU), et surtout affiche les noms des dĂ©veloppeurs et les messages de copyright et clauses de licences obligatoires de logiciels libres qui sont embarquĂ©s dans Haiku.

Correction d’un crash Ă  cause d’une information de copyright mal enregistrĂ©e (madmax).

Mise Ă  jour des crĂ©dits Ă  l’occasion de la version Beta 5 : ajout des nouveaux membres de l’équipe, et passage dans la catĂ©gorie « anciens dĂ©veloppeurs » de certaines personnes qui ne participent plus pour l’instant. (waddlesplash).

DĂ©bogueur

Haiku est fourni avec un dĂ©bogueur graphique permettant d’investiguer facilement les problĂšmes dans les applications.

Waddlesplash a amĂ©liorĂ© le dĂ©sassembleur pour mieux dĂ©coder les adresses mĂ©moire calculĂ©es Ă  partir de la valeur d’un registre CPU. La correction a Ă©tĂ© remontĂ©e dans la bibliothĂšque tierce Zydis, utilisĂ©e pour le dĂ©sassemblage.

Il a Ă©galement modifiĂ© le code du Debugger pour ne pas essayer de tĂ©lĂ©charger des informations de debug lorsque l’outil est lancĂ© en mode non-interactif (dans le cas d’une test suite automatisĂ©e par exemple). Plusieurs autres problĂšmes qui pouvaient causer un plantage du debugger ou un blocage dans un Ă©tat invalide (avec l’application qui ne s’arrĂȘte jamais) ont Ă©tĂ© Ă©galement traitĂ©s.

DriveSetup

L’outil DriveSetup permet de modifier la table de partitions et de formater les partitions avec diffĂ©rents systĂšmes de fichiers.

Pour les partitions de type « Intel » (MBR), lorsqu’on crĂ©e une premiĂšre partition, par dĂ©faut elle est marquĂ©e automatiquement comme partition active. Auparavant il fallait cocher une case pour cela, et de nombreux utilisateurs oubliaient de le faire, ce qui pouvait rendre le systĂšme impossible Ă  dĂ©marrer (korli).

Dans certains messages, le nom des partitions n’était pas mis entre guillemets, ce qui pouvait prĂȘter Ă  confusion avec des noms de partitions choisis maladroitement (ou judicieusement, selon de quel point de vue on se place). Maintenant le nom de la partition est clairement identifiable dans le message (humdinger).

HaikuDepot

HaikuDepot est le frontal graphique du gestionnaire de paquets de Haiku. L’application est maintenue par apl et se compose d’une interface graphique native dĂ©veloppĂ©e en C++ et d’un webservice dĂ©veloppĂ© en Java qui permet de stocker des mĂ©tadonnĂ©es supplĂ©mentaires sur les paquets : captures d’écrans, notes et revues des utilisateurs, liste des paquets Ă  mettre en avant.

  • Refactoring du « language model Â», de la gestion des chemins, de la rĂ©cupĂ©ration des donnĂ©es des paquets, de l’affichage des auteurs de paquets, de la gestion des notes donnĂ©es par les utilisateurs. (apl)
  • FenĂȘtre des conditions d’utilisation: correction de la couleur du texte, correction d’un crash si on clique dans la fenĂȘtre avant que le texte soit chargĂ©. (apl et jscipione)
  • Le bouton « Ouvrir » permettant de lancer une application installĂ©e ne fonctionnait pas toujours (apl).
  • AmĂ©lioration de la sĂ©lection d’un icĂŽne par dĂ©faut pour les paquets qui n’ont pas d’icĂŽne inclus (apl).

La liste de paquets mis en avant a Ă©tĂ© revue, un nouveau mainteneur (Michel) se charge de la tenir Ă  jour avec des rĂšgles mieux dĂ©finies : une sĂ©lection d’applications populaires (sur suggestion de participants aux forums de discussion) ainsi que des applications mises Ă  jour rĂ©cemment. Si vous utilisez Haiku, n’hĂ©sitez pas Ă  passer un peu de temps Ă  Ă©valuer et noter les applications, peu de personnes le font et il est difficile d’exploiter les donnĂ©es de façon pertinente si beaucoup d’applications n’ont reçu qu’un seul vote.

Horloge

L’application horloge permet d’afficher l’heure (sans surprise). Elle propose diverses apparences de cadrans, peut ĂȘtre redimensionnĂ©e, et incrustĂ©e dans le bureau sous forme d’un replicant.

Un bug dans l’application conduisait Ă  afficher une heure alĂ©atoire (non initialisĂ©e) pendant quelques centiĂšmes de secondes au dĂ©marrage avant de commencer Ă  afficher l’heure courante (OscarL)

Les aiguilles de l’horloge Ă©taient dĂ©calĂ©es de quelques pixels et ne pointaient pas prĂ©cisĂ©ment lĂ  ou elles devraient (dovsienko).

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il affiche le bureau et toutes les fenĂȘtres de navigation et de recherche de fichiers. Il se distingue par son utilisation de la navigation dite « spatiale Â», oĂč chaque dossier s’ouvre dans une fenĂȘtre sĂ©parĂ©e dont la taille et la position Ă  l’écran sont mĂ©morisĂ©es.

jscipione continue son travail d’amĂ©lioration du Tracker (cela comporte de nombreux changements qui sont encore en gestation). Ce trimestre, les changements intĂ©grĂ©s permettent :

  • la dĂ©sactivation d’entrĂ©es du menu « Nouveau » lorsque les opĂ©rations ne sont pas disponibles,
  • la mise Ă  jour dynamique de certains menus en fonction des opĂ©rations disponibles,
  • la prĂ©servation de la sĂ©lection aprĂšs une opĂ©ration de copie oĂč de dĂ©placement (avec quelques problĂšmes d’affichage corrigĂ©s au passage),
  • des corrections de bug sur le choix de couleurs utilisĂ©es dans la fenĂȘtre « Ouvrir avec »,
  • la possibilitĂ© de crĂ©er un lien symbolique lorsqu’on fait un drag and drop depuis un dossier virtuel,
  • utilisation de la police de caractĂšres « menu » de façon cohĂ©rente dans tous les menus.

Il a Ă©galement travaillĂ© sur des tĂąches de fond, sans changements visibles pour l’instant. Le code du Tracker provient de BeOS et est un peu vieillissant. Il est souvent nĂ©cessaire de faire beaucoup de nettoyage avant de pouvoir dĂ©velopper de nouvelles fonctionnalitĂ©s sans casser autre chose. Cette fois-ci, on trouve entre autres une refonte de la gestion des raccourcis claviers, la fermeture automatique des fenĂȘtres en double lors du passage en mode « navigation spatiale », et divers crashs liĂ©s Ă  la gestion des menus popup.

humdinger a également travaillé sur le Tracker pour améliorer certains messages concernant la copie et la création de fichiers, pour les rendre plus faciles à traduire.

humdinger a Ă©galement travaillĂ© sur l’organisation du menu « templates » (affichĂ© quand on fait un clic droit -> nouveau
 et permettant de crĂ©er diffĂ©rents types de fichiers Ă  partir de fichiers de rĂ©fĂ©rence). Ce menu peut maintenant ĂȘtre organisĂ© en plusieurs sous-menus Ă  l’aide d’une nouvelle option « New template folder », pour les personnes qui utilisent cette fonctionnalitĂ© avec de nombreux fichiers de rĂ©fĂ©rence au point d’avoir besoin de les organiser.

La fenĂȘtre de requĂȘtes (recherche de fichiers en fonction de leurs attributs Ă©tendus indexĂ©s dans le systĂšme de fichiers) permet maintenant d’afficher en temps rĂ©el les rĂ©sultats lorsqu’on Ă©dite une requĂȘte. En outre, il est possible de filtrer les rĂ©sultats pour afficher uniquement les fichiers contenus dans un rĂ©pertoire donnĂ© (auparavant, on pouvait au mieux restreindre par volume disque). Ces changements ont Ă©tĂ© rĂ©alisĂ©s dans le cadre du Google Summer of Code par CalistoMathias, avec Ă©galement une participation de jscipione, humdinger et waddleplash pour finaliser le travail.

Correction d’un crash du Tracker lors de changements de rĂ©solution d’écran (OscarL).

Terminal

Le Terminal permet d’exĂ©cuter des applications en ligne de commande.

Lors du changement de la taille de texte du Terminal, ce dernier ajuste le nombre de lignes et colonnes de texte visibles, au lieu de redimensionner sa fenĂȘtre (nipos).

Prise en compte de la sĂ©quence d’échappement ANSI pour effacer l’historique de dĂ©filement (CodeForEvolution).

PowerStatus

L’application PowerStatus affiche des informations sur les batteries pour les ordinateurs portables.
sen a effectué plusieurs améliorations pour les systÚmes avec plusieurs batteries:

  • Gestion de plusieurs emplacements pour batteries qui ne sont pas forcĂ©ment tous utilisĂ©s,
  • Meilleur calcul des alertes de batterie faible,
  • Prise en compte de la dĂ©connexion de batteries pendant le fonctionnement du systĂšme.

Outils en ligne de commande

La commande profile (qui permet d’analyser les performances d’autres applications et du systĂšme) peut maintenant afficher le nombre d’évĂšnements qui n’ont pas pu ĂȘtre enregistrĂ©s par l’analyseur systĂšme (waddlesplash).

La commande package_repo update (utilisée pour mettre à jour un dépÎt de paquets avec de nouveaux logiciels) peut maintenant fonctionner sans avoir accÚs au contenu complet des fichiers packages à inclure dans le dépÎt (seuls les noms des paquets et quelques autres métadonnées sont réellement nécessaires).

La commande package_repo list dispose d’une option -f pour afficher le nom de fichiers correspondant aux paquets contenus dans un dĂ©pĂŽt de paquets. Les fichiers peuvent ainsi ĂȘtre tĂ©lĂ©chargĂ©s facilement par un outil tiers. (waddlesplash)

Ces deux modifications sont utiles en particulier pour la ferme de build de HaikuPorts, qui souhaite hĂ©berger les fichiers dans des buckets S3 afin de simplifier l’infrastructure et de rĂ©duire les coĂ»ts de fonctionnement.

Amélioration du format de sortie de la commande launch_roster pour indiquer le statut des services et pas simplement leur nom (kallisti5 + waddlesplash).

Ajout dans strace du décodage des drapeaux de configurations de mutex (par exemple MUTEX_SHARED) (waddlesplash).

Serveurs

Les serveurs sont des applications fonctionnant en tùche de fond et qui implémentent une grande partie des fonctionnalités du systÚme.

app_server

app_server est le serveur graphique qui se charge de l’affichage du bureau et des fenĂȘtres.

madmax a travaillĂ© sur la gestion des polices de caractĂšres: correction de problĂšmes de verrouillage pour Ă©viter des accĂšs concurrents au gestionnaire de polices par plusieurs fils d’exĂ©cution, amĂ©lioration du traitement de l’ajout et du retrait de polices, et une optimisation pour Ă©viter de scanner deux fois de suite les dossiers de polices au dĂ©marrage.

waddlesplash a complĂ©tĂ© ce changement en dĂ©plaçant une partie du code de gestion des polices pour Ă©viter que d’autres parties de l’exĂ©cution soient bloquĂ©es par l’initialisation des polices, qui peut prendre beaucoup de temps (quelques secondes) au dĂ©marrage du systĂšme.

waddlesplash a corrigĂ© un problĂšme de calcul de dĂ©lai d’expiration (probablement sans consĂ©quence, dĂ©couvert par hasard en investiguant un autre problĂšme).

jscipione a corrigĂ© un problĂšme de rafraĂźchissement de l’affichage lorsque des fenĂȘtres sont empilĂ©es, qui pouvait conduire Ă  ne pas bien effacer la barre de titre dans certains cas.

Un clic simple sur le coin bas-droite de la fenĂȘtre (coin de redimensionnement) dĂ©clenchait par erreur une minimisation de la fenĂȘtre concernĂ©e (madmax).

media_server

Le media_server prend en charge les flux audio et vidĂ©o et permet de router ces flux entre diffĂ©rentes applications ainsi que depuis et vers le matĂ©riel (cartes son, cartes d’acquisition vidĂ©o, webcams
).

Travaux effectués par waddlesplash:

Correction de problĂšmes de calculs de temps dans le mixeur audio (problĂšmes dĂ©couverts suite Ă  l’amĂ©lioration de la dĂ©tection d’erreurs dans BTimeSource, mentionnĂ© plus haut), et ajout de contrĂŽles d’intĂ©gritĂ© supplĂ©mentaires lors du dĂ©marrage du mixeur.

Cela corrige plusieurs bugs qui faisaient que le systĂšme n’avait pas de son au dĂ©marrage pendant un certain temps, avant que soudainement ça se mette Ă  fonctionner.

D’autre part, des amĂ©liorations de performance sur la programmation des Ă©vĂšnements, et des corrections de crash sur la connexion et dĂ©connexion des nƓuds mĂ©dia vers la sortie audio, et sur le nƓud multi-audio avec certaines cartes sons qui exposent des types de contrĂŽles invalides.

D’autres changements sont en cours pour pouvoir changer la sortie audio sans avoir besoin de redĂ©marrer le serveur mĂ©dia, mais ça ne fonctionne pas encore.

registrar

Le registrar surveille quelles sont les applications déjà lancées et fournit divers services de communication entre applications, en particulier pour le presse-papier.

Ajout de vĂ©rification d’erreurs si un message de rĂ©cupĂ©ration du contenu du presse-papier Ă©choue. Cela peut arriver si on a mis beaucoup de donnĂ©es dans le presse-papier et qu’il n’y a plus assez de mĂ©moire disponible.

Des corrections du cĂŽtĂ© de la libbe permettent maintenant de gĂ©rer ces erreurs et de ne pas faire planter l’application concernĂ©e.

input_server

L’input_server` se charge des pĂ©riphĂ©riques d’entrĂ©e (clavier, souris
)

AmĂ©liorations la validation des donnĂ©es des fichiers de configuration de souris, qui dans certains cas pouvaient empĂȘcher la souris de fonctionner. Refonte de la gestion des accĂšs concurrents Ă  la liste des pĂ©riphĂ©riques, pour supprimer des verrous inutiles et permettre les accĂšs Ă  la liste mĂȘme si un thread de gestion d’un pĂ©riphĂ©rique est bloquĂ©. (madmax)

Les codes de touches pour la touche power et la touche \_ des claviers japonais s’étaient retrouvĂ©s assignĂ©es Ă  des valeurs identiques (cela semble provenir tout droit de changements datant de BeOS, car ces touches non prĂ©sentes sur un clavier de PC amĂ©ricain classiques sont assez mal documentĂ©es). La documentation a Ă©tĂ© mise Ă  jour pour mieux expliquer quels sont les codes utilisĂ©s, et les diffĂ©rents pilotes (PS2, USB) ont Ă©tĂ© harmonisĂ©s pour utiliser les mĂȘmes codes (x512 et PulkoMandy).

Le code power pourra Ă©galement ĂȘtre utilisĂ© par un pilote GPIO sur les machines oĂč c’est nĂ©cessaire (souvent non compatibles PC).

net_server

Le net_server se charge de toutes les opérations liées au réseau.

mmlr a corrigé un problÚme dans le client DHCP, qui utilisait certaines variables sans les initialiser.

package_daemon

Le package_daemon vĂ©rifie la cohĂ©rence des paquets installĂ©s avec leurs dĂ©pendances, crĂ©e les dossiers de transactions et de sauvegarde de l’état passĂ© du systĂšme, et se charge de lancer les scripts d’activation et de dĂ©sactivation de paquets. L’accĂšs au contenu des paquets est en revanche traitĂ© dans le noyau par le systĂšme de fichier packagefs.

Changement des couleurs des fenĂȘtres « problĂšmes » et « rĂ©sultats » qui apparaissent quand il y a des conflits ou d’autres problĂšmes de rĂ©solution de dĂ©pendances lors de l’activation des paquets (jscipione).

Kits

Les « kits » sont les composants de la bibliothĂšque standard de Haiku. Il s’agit principalement d’une convention de documentation et d’organisation de code source pour regrouper des fonctionnalitĂ©s liĂ©es entre elles.

Interface

L’interface kit` permet l’ouverture de fenĂȘtre et l’ajout de contrĂŽles d’interface graphiques Ă  l’intĂ©rieur de ces derniĂšres.

Les objets BBitmap (permettant de stocker une image « raster ») avec le flag ACCEPT_VIEWS (permettant d’attacher une « vue" pour dessiner dans le bitmap ne sont plus automatiquement effacĂ©s. Cela permet de crĂ©er un bitmap Ă  partir de donnĂ©es existantes, puis de dessiner autre chose par-dessus. Ce changement corrige un problĂšme de compatibilitĂ© avec BeOS, et permet aussi d’utiliser cette mĂ©thode dans l’implĂ©mentation de WebKit pour Haiku (ZardShard).

Un changement prĂ©cĂ©dent avait causĂ© un problĂšme de compatibilitĂ© d’API avec BeOS, qui dĂ©clenchait dans certains cas une rĂ©cursion infinie et un crash lorsqu’on essayait de faire dĂ©filer une BListView par glisser-dĂ©placer (par exemple dans l’application Wonderbrush). Waddlesplash a corrigĂ© ce problĂšme, et jscipione a Ă©galement ajoutĂ© quelques amĂ©liorations sur la mise Ă  jour des items sĂ©lectionnĂ©s lorsqu’on effectue cette opĂ©ration.

Il est maintenant possible d’afficher des « checkmarks » (coche indiquant une option activĂ©e) sur les items de menus disposĂ©s en « matrice ». Habituellement les menus sont soit disposĂ©s sur une ligne, soit sur une colonne avec les items les un au-dessous des autres. Le mode « matrice » permet de s’affranchir de ces restrictions pour disposer les items librement avec du code applicatif.

Mise Ă  jour en direct des couleurs dans les contrĂŽles BSpinner, refonte de l’hĂ©ritage des couleurs de la vue parente, et changement de la couleur de fond des boutons en mode sombre (jscipione).

Centrage vertical des dates dans BCalendarView (permettant d’afficher un calendrier) (nipos).

Factorisation de code dans BView pour l’envoi des donnĂ©es BShape vers app_server (x512).

La méthode de debug BPoint::PrintToStream affiche maintenant les coordonnées avec des décimales, permettant de détecter les points qui ne sont pas alignés avec la grille de pixels (ayu-ch).

Les boĂźtes de texte marquĂ©es comme « invalides » ont maintenant un fond rouge. La bordure rouge utilisĂ©e prĂ©cĂ©demment n’était pas assez visible (nephele).

Media

Le media kit permet aux applications de s’interfacer avec le media server, et fournit en plus une interface standardisĂ©e pour les codecs audio et vidĂ©o.

Ajout d’assertions dans la classe BTimeSource pour empĂȘcher les applications d’envoyer des temps avec un « drift » infĂ©rieur ou Ă©gal Ă  0. Le « drift" est utilisĂ© comme multiplicateur et diviseur dans les calculs d’horloge, donc les valeurs infĂ©rieures ou Ă©gales Ă  0 causent des problĂšmes. Ceci a Ă©tĂ© mis en Ă©vidence par des corrections au niveau du noyau (voir plus loin dans la dĂ©pĂȘche) et a ensuite permis de trouver encore d’autres problĂšmes en particulier dans les add-ons media (waddlesplash).

Locale

Le « locale Â» kit permet la traduction des applications, le formatage des nombres en fonction des prĂ©fĂ©rences de chaque pays, la gestion des fuseaux horaires, et toutes les autres problĂ©matiques liĂ©es Ă  l’internationalisation. Il s’agit principalement d’un enrobage de la bibliothĂšque ICU pour faciliter son utilisation avec les types natifs de Haiku.

Meilleure gestion des erreurs si la bibliothĂšque ICU ne peut pas ĂȘtre initialisĂ©e (waddlesplash).

Support

Le support kit contient diverses méthodes et classes utilitaires et génériques.

ContrĂŽle d’intĂ©gritĂ© des donnĂ©es lors de la dĂ©serialisation de BMessage (waddlesplash).

Correction d’incohĂ©rence de nommage de paramĂštres de fonction entre les fichiers .cpp et .h dĂ©tectĂ©s par cppcheck (mt).

Pilotes de périphériques

Les pilotes sont indispensables pour assurer le fonctionnement de Haiku sur une grande variĂ©tĂ© de matĂ©riel. Certains sont dĂ©veloppĂ©s Ă  partir des spĂ©cifications du matĂ©riel spĂ©cifiquement pour Haiku, et d’autres ont Ă©tĂ© adaptĂ©s de travaux rĂ©alisĂ©s pour d’autres systĂšmes d’exploitation.

Le niveau de logging par défaut a été abaissé dans certains pilotes afin de ne pas trop polluer le journal systÚme, en particulier:

  • Suppression de messages indiquant qu’aucun matĂ©riel compatible avec le pilote n’a Ă©tĂ© dĂ©tectĂ©,
  • Suppression de certains logs de debug dans les pilotes audio HDA et usb_audio.

Processeurs et Ă©conomie d’énergie

Renommage du pilote intel_cstates en x86_cstates puisque les processeurs récents de chez AMD sont également pris en charge par ce pilote.

Appel Ă  ce pilote Ă  plus d’endroits dans le noyau pour mettre les processeurs en veille ou au ralenti quand ils ne sont pas utilisĂ©s.

RĂ©seau

virtio_net

Le pilote virtio_net (carte rĂ©seau utilisĂ©e dans les machines virtuelles) implĂ©mente maintenant le « checksum offloading » pour les protocoles IP, TCP et UDP. En effet, dans le cas de ce pilote, les vĂ©rifications et calculs de sommes d’intĂ©gritĂ© doivent ĂȘtre faits de toutes façons du cĂŽtĂ© de la machine hĂŽte, il est donc inutile de les refaire dans la machine virtuelle.

Au passage, correction de quelques erreurs dans ce driver, et en particulier de problÚmes de calcul de taille de buffers en mémoire.

broadcom750x

Utilisation des interruptions par messages (MSI) lorsque c’est nĂ©cessaire pour certaines versions du matĂ©riel (waddlesplash).

 vmxnet

Nouveau pilote portĂ© depuis FreeBSD qui permet d’utiliser l’interface rĂ©seau paravirtualisĂ©e de VMWare (CodeForEvolution).

 Couches de compatibilitĂ© BSD

Haiku utilise des pilotes réseau venus de FreeBSD et OpenBSD, cela permet de mutualiser les ressources et de ne pas perdre du temps à réinventer la roue. Une couche de compatibilité permet de réutiliser les pilotes avec trÚs peu de modification dans leur code et une simple recompilation.

Cette approche est Ă©galement utilisĂ©e par d’autres systĂšmes d’exploitation comme RTEMS.

La couche de compatibilitĂ© a reçu des corrections de problĂšmes sur l’allocation de mĂ©moire dĂ©diĂ©e aux transferts DMA, ainsi qu’un problĂšme sur le calcul de la taille d’un buffer de rĂ©ception, qui empĂȘchait les pilotes de fonctionner sur certains matĂ©riels.

 TCP

Waddlesplash a travaillĂ© sur l’amĂ©lioration de l’implĂ©mentation de TCP :

  • Refonte de la gestion des ACK reçus dans le dĂ©sordre,
  • AmĂ©lioration du code de dĂ©bogage pour investiguer des crashs du noyau remontĂ©s par quelques utilisateurs,
  • Modification du code de mise Ă  jour de la taille de fenĂȘtre TCP pour Ă©viter d’envoyer inutilement des changements de taille,
  • Correction de calcul du temps d’aller-retour,
  • ImplĂ©mentation du redimensionnement dynamique de la fenĂȘtre de rĂ©ception (auparavant, elle Ă©tait de taille fixe),
  • Ajout d’assertions Ă  divers endroits dans la pile rĂ©seau pour dĂ©tecter les problĂšmes Ă  la source.

Ces amĂ©liorations permettent au trafic TCP d’ĂȘtre au moins 10 fois plus rapide, selon le type de connexion utilisĂ©, et rĂšgle un problĂšme de lenteur des tĂ©lĂ©chargements depuis Haiku qui Ă©tait prĂ©sent depuis assez longtemps.

 Ethernet

Du cĂŽtĂ© d’Ethernet, quelques amĂ©liorations et nettoyages sur le calcul de la MTU (taille maximale d’un paquet qui peut ĂȘtre envoyĂ©). Pour l’instant, la dĂ©couverte du « path MTU », la MTU du chemin complet entre deux machines, n’est pas encore disponible. Haiku ne s’autorise donc pas Ă  envoyer du trafic plus large qu’une trame Ethernet standard, mĂȘme si cela pourrait ĂȘtre possible pour le rĂ©seau local. Il reste donc une amĂ©lioration potentielle des performances rĂ©seau dans certains cas.

 UNIX domain sockets

Les sockets UNIX sont une mĂ©thode de communication entre processus standardisĂ©e par POSIX, utilisĂ©e surtout par des logiciels portĂ©s depuis d’autres systĂšmes (les applications natives pour Haiku utiliseront plus volontiers des BMessages ou des ports).

AmĂ©lioration et nettoyage du code autour de la gestion des donnĂ©es annexes dans les sockets UNIX. Correction de petites fuites de mĂ©moire et d’un kernel panic qui pouvait se produire lors de la fermeture d’un socket (waddlesplash).

USB

ImplĂ©mentation de l’USB « Super Speed Plus », qui permet des connexions USB avec un dĂ©bit pouvant atteindre 10 gigabits par seconde (korli).

Refonte et consolidation du comptage de rĂ©fĂ©rences dans la pile USB, ce qui met en Ă©vidence sous forme de kernel panic des cas oĂč les choses ne sont pas bien faites. Ce n’est pas agrĂ©able, mais c’est tout de mĂȘme mieux qu’une corruption mĂ©moire difficile Ă  investiguer (waddleplash).

DĂ©codage des descripteurs USB Audio v2 dans la commande listusb, mais pas encore dans le pilote usb_audio qui implĂ©mente pour l’instant seulement la version 1 (gscrain).

PCI

Correction de problĂšmes d’accĂšs au bus PCI sur les machines Ă©quipĂ©es de ACPI. Suite Ă  une modification prĂ©cĂ©dente, les accĂšs sur 8 ou 16 bits Ă©taient convertis en accĂšs sur 32 bits, mais ce n’est pas le comportement attendu. En particulier, certains registres effacent automatiquement leur contenu lorsqu’ils sont lus, ou bien les donnĂ©es accessibles en lecture et en Ă©criture ne sont pas les mĂȘmes. (PulkoMandy)

Il n’est donc pas possible de lire une valeur sur 32 bits, remplacer 8 bits, et rĂ©Ă©crire 32 bits pour simuler une Ă©criture sur 8 bits dans un registre.

Les accĂšs sont Ă  nouveau traitĂ©s correctement, ce qui permet Ă  Haiku de fonctionner Ă  nouveau normalement sur les machines concernĂ©es par ce type d’accĂšs au bus PCI (cela dĂ©pend du matĂ©riel et des pilotes).

Périphériques de stockage

Petites améliorations de performances dans le pilote NVMe (waddlesplash).

Modification du pilote AHCI/SATA (waddlesplash) :
- Suppression de code dupliquĂ© pour utiliser Ă  la place des fonctions communes partagĂ©es avec d’autres pilotes,
- Correction d’une confusion entre adresses 32 et 64 bits qui empĂȘchait de dĂ©marrer la version 32
bits de Haiku sur certains systĂšmes avec plus de 4Gio de RAM.

La pile SCSI prend mieux en compte les restrictions sur les adresses DMA. Chaque pilote de pĂ©riphĂ©rique qui implĂ©mente SCSI peut indiquer ce qu’il est capable de faire, et la pile SCSI fait en sorte que les demandes de transferts DMA respectent ces contraintes, ce qui Ă©vite aux pilotes de devoir dĂ©couper par eux-mĂȘmes les transferts en unitĂ©s qu’ils sont capables de traiter (waddlesplash).

ACPI

ACPI est une interface standardisĂ©e avec le matĂ©riel. Elle permet la gestion d’énergie (extinction de la machine par exemple), ainsi que l’accĂšs Ă  du matĂ©riel annexe tels que les boutons on/off, la dĂ©tection de rabat de l’écran sur un PC portable, le contrĂŽle des LEDs indicatrices ; ainsi que la dĂ©couverte de matĂ©riel non connectĂ© sur le bus PCI (comme certains modules eMMC dans des tablettes et ordinateurs Ă  bas coĂ»t).

La spĂ©cification Ă©tant assez complexe, la bibliothĂšque ACPICA est utilisĂ©e pour implĂ©menter les bases de ACPI. Ensuite, des pilotes dĂ©diĂ©s permettent d’exposer chaque pĂ©riphĂ©rique ACPI.

Mise à jour de ACPICA avec la derniÚre version publiée par Intel (publiée en mars), et un peu de nettoyage afin de pouvoir intégrer quelques patchs dans la version upstream de ACPICA (PulkoMandy).

Ajustement du pilote ACPI pour mapper sa mĂ©moire physique en « write back » au lieu de dĂ©sactiver complĂštement le cache. C’est nĂ©cessaire sur ARM64, car le cache permet d’intercepter les accĂšs mĂ©moire non alignĂ©s. Correction de problĂšmes liĂ©s au fait que la mĂȘme zone de mĂ©moire physique pouvait ĂȘtre mappĂ©e plusieurs fois avec des configurations diffĂ©rentes, ce qui est impossible (dĂ©clenche une « machine check exception ») (oanderso).

Graphiques

AvancĂ©es sur la prise en charge des cartes graphiques Intel de gĂ©nĂ©rations Tiger Lake, Ice Lake et Gemini Lake (ttmfx, ilzu, PulkoMandy). L’utilisation de ces cartes graphiques reste assez limitĂ©, sans accĂ©lĂ©ration matĂ©rielle et sans possibilitĂ© d’utiliser plusieurs Ă©crans pour l’instant.

virtio

Les pilotes virtio permettent l’utilisation de matĂ©riel virtuel dĂ©fini pour tirer le meilleur parti des machines virtuelles. PlutĂŽt que de copier le fonctionnement d’un matĂ©riel existant, l’interface peut ĂȘtre conçue pour rendre le travail plus simple aussi bien pour l’hĂŽte que pour le systĂšme virtualisĂ©.

Correction de problĂšmes dans l’allocation des files de messages virtio et amĂ©lioration de la gestion des erreurs (mmlr).

VĂ©rification de l’état du pĂ©riphĂ©rique aprĂšs une rĂ©initialisation, et correction d’un accĂšs mĂ©moire hors limite dans le pilote virtio_pci (korli).

PS/2

Les ports PS/2 ont disparu de la plupart des machines depuis de nombreuses annĂ©es, mais le protocole est encore utilisĂ© pour les claviers des ordinateurs portables ainsi que pour certains touchpads. Ces derniers utilisent de nombreuses extensions peu standardisĂ©es et mal documentĂ©es pour offrir des fonctions avancĂ©es qui n’existaient pas Ă  l’époque des souris Ă  deux boutons.

Le driver reçoit ce trimestre une refonte de la gestion des verrous entre ses différents composants, pour essayer de régler quelques problÚmes de synchronisation (waddlesplash).

SystĂšmes de fichiers

ram_disk et ramfs

ram_disk est un pĂ©riphĂ©rique bloc (block device) qui stocke ses donnĂ©es en RAM (non persistante au redĂ©marrage). Il peut ĂȘtre formatĂ© avec n’importe quel systĂšme de fichier.

ramfs est un systĂšme de fichiers qui stocke ses donnĂ©es en RAM, sans passer par un block device. Cela permet de meilleures performances (pas besoin de journalisation par exemple), une meilleure intĂ©gration avec le cache de fichiers (la mĂ©moire peut ĂȘtre partagĂ©e directement entre ramfs et le cache), et de s’affranchir des limites habituelles des pĂ©riphĂ©riques de bloc (par exemple: une taille fixe connue lors de la crĂ©ation du systĂšme de fichiers).

Un utilisateur a remontĂ© un problĂšme de compatibilitĂ© avec POSIX. Si on utilise mmap() sur un fichier stockĂ© dans un ramfs, et que la taille du fichier n’est pas un multiple de la taille des pages de mĂ©moire, la fin de la derniĂšre page pouvait contenir des donnĂ©es alĂ©atoires. Selon la spĂ©cification POSIX, il faut que cette zone soit remplie avec des 0, et le compilateur clang dĂ©pend de ce comportement pour implĂ©menter une lecture rapide des fichiers sources compilĂ©s.

Le problÚme a été corrigé, avec au passage une commonalisation de code entre ramfs et ram_disk, de petits ajustements de performances, et un peu de nettoyage.

Enfin, la prioritĂ© des allocations mĂ©moires de ces deux pilotes a Ă©tĂ© abaissĂ©e, ce qui permet d’éviter un gel du systĂšme s’il n’y a plus de mĂ©moire disponible.

Le pilote ramfs continue d’ĂȘtre stabilisĂ©, quelques problĂšmes qui pouvaient encore causer des kernel panic ont Ă©tĂ© corrigĂ©s.

packagefs

packagefs est un systĂšme de fichier virtuel qui expose le contenu de fichiers de packages au format hpkg. Des paquets peuvent ĂȘtre ajoutĂ©s et supprimĂ©s pendant le fonctionnement du systĂšme, et il n’est pas nĂ©cessaire d’extraire leurs donnĂ©es sur disque.

Plusieurs améliorations faites par waddlesplash :

  • Ajout de vĂ©rifications de la bonne utilisation de verrous entre diffĂ©rents threads et corrections de problĂšmes mineurs qu’elles ont mis en Ă©vidence,
  • AmĂ©lioration du message d’erreur si on essaie d’activer deux paquets qui entrent en conflit.

Un reproche qui est souvent fait au packagefs est d’avoir augmentĂ© les besoins en RAM de Haiku, en effet, depuis la version Beta 1 de Haiku, la configuration mĂ©moire minimum recommandĂ©e est de 384Mio de RAM, alors que les versions prĂ©cĂ©dentes se contentaient de 128Mio.

  • Utilisation d’object_cache` (un allocateur mĂ©moire pour des objets qui font tous la mĂȘme taille) dans diffĂ©rents endroits de packagefs pour rĂ©duire sa consommation de mĂ©moire,
  • Utilisation de listes chaĂźnĂ©es simples au lieu de listes chaĂźnĂ©es doubles lĂ  oĂč ça ne pose pas de problĂšme de performances,
  • Suppression de champs constants dans certaines classes,
  • « inlining » des compteurs de rĂ©fĂ©rences pour rendre les structures de donnĂ©es plus compactes,
  • RĂ©organisation des structures pour rĂ©duire le padding,
  • Retrait des « dĂ©pĂŽts d’objets » dans les arĂšnes d'allocation,
  • DĂ©coupage des allocations en plusieurs zones distinctes,
  • Utilisation de verrous moins fins (par exemple, avoir un seul verrou pour tout un dossier au lieu de un par fichier),
  • Utilisation d’un « bump allocator » pour les objets Ă  courte durĂ©e de vie.

La rĂ©duction de consommation mĂ©moire avec ces changements est de prĂšs de 20%, soit environ 15Mio sur une installation de rĂ©fĂ©rence. En effet, un gain de quelques octets sur le stockage d’informations sur un fichier est multipliĂ© par plusieurs milliers de fichiers prĂ©sents sur le disque, ce qui fait que chaque petite optimisation est intĂ©ressante. Cependant, les investigations ont aussi permis de dĂ©couvrir d’autres problĂšmes encore plus importants qui n’étaient pas directement liĂ©s au packagefs, on en reparle un peu plus loin.

Un autre changement a Ă©tĂ© fait par waddlesplash, non seulement pour packagefs mais aussi pour d’autres endroits oĂč le mĂȘme code Ă©tait utilisĂ© : La fonction pour calculer un hash de chaĂźne de caractĂšres utilisait un algorithme obsolĂšte. Elle a Ă©tĂ© remplacĂ©e par hashdjb2 qui gĂ©nĂšre moins de collisions.

FAT

FAT est un systÚme de fichier développé par Microsoft. Il est utilisé en particulier sur les cartes SD et les clés USB, ainsi que pour les partitions systÚmes EFI. Bien que sa conception soit quelque peu obsolÚte, il reste donc indispensable.

Le pilote FAT de Haiku, qui provenait tout droit d’un code source publiĂ© par Be, a Ă©tĂ© remplacĂ© dans la version beta 5 par une nouvelle version basĂ©e sur le code de FreeBSD. Ce nouveau pilote reçoit depuis des amĂ©liorations rĂ©guliĂšres par Jim906, le dĂ©veloppeur qui s’est chargĂ© du portage du code de FreeBSD.

Ce trimestre, le pilote reçoit des corrections sur l’initialisation des « media bytes » dans l’en-tĂȘte des partitions, des amĂ©liorations de performances pour rĂ©duire le temps nĂ©cessaire au montage d’une partition FAT, ainsi qu’une meilleure gestion des erreurs dans le traitement des noms de volumes. Il est Ă©galement possible de monter les volumes FAT de taille supĂ©rieure Ă  2TiO.

BFS

BFS est le systĂšme de fichier hĂ©ritĂ© de BeOS et utilisĂ© pour les partitions natives de Haiku. Il propose une trĂšs bonne implĂ©mentation des attributs Ă©tendus (sans limite de taille, et typĂ©s) et permet en plus d’exĂ©cuter des requĂȘtes sur ces attributs pour localiser trĂšs rapidement les fichiers rĂ©pondant Ă  certains critĂšres.

L’implĂ©mentation du systĂšme de fichier BFS est assez mĂ»re et reçoit habituellement peu d’évolutions. Cependant, il reste toujours des possibilitĂ©s d’amĂ©liorer les performances.

C’est le cas de la fonction de recherche de blocs libres. Les blocs sont chacun reprĂ©sentĂ©s par un bit dans une structure indiquant s’ils sont disponibles ou pas. La recherche de blocs libres se faisait bit Ă  bit, mais il est possible de gagner beaucoup de temps en testant 64 bits d’un coup pour savoir tout de suite qu’ils reprĂ©sentent tous des blocs occupĂ©s, et passer directement aux 64 bits suivants. Cela amĂ©liore les performances de la crĂ©ation et du redimensionnement de fichier, en particulier sur les architectures RISC-V (waddlesplash).

Query parser

Plusieurs systĂšmes de fichiers conçus pour BeOS ou Haiku (bfs, ramfs, et packagefs) permettent l’utilisation d’attributs indexĂ©s par le systĂšme de fichiers qui permettent d’effectuer des requĂȘtes pour localiser des fichiers comme dans une base de donnĂ©es.

Depuis la version beta 5 de Haiku, ces 3 systĂšmes de fichiers partagent le code utilisĂ© pour parser une requĂȘte (envoyĂ©e sous forme de texte) et la convertir en une opĂ©ration de recherche exĂ©cutable.

Ce parser pouvait dans certains cas (requĂȘtes trop complexes) dĂ©clencher volontairement un kernel panic. Celui-ci a Ă©tĂ© remplacĂ© par une « simple » erreur, remontĂ©e Ă  l’application qui a dĂ©clenchĂ© la requĂȘte. L’application aura la charge de remonter cette erreur Ă  l’utilisateur, et de l’inviter Ă  simplifier sa demande.

block_cache

Le cache de blocs, comme son nom l’indique, stocke en mĂ©moire RAM une copie de certains blocs des systĂšmes de fichiers. Cela permet d’accĂ©lĂ©rer les opĂ©rations bas niveau sur le systĂšme de fichier, en particulier pour mettre en cache des structures internes du disque. Il complĂšte le file_cache, qui lui se trouve Ă  un niveau plus haut, et met en cache uniquement le contenu des fichiers lus et Ă©crits par les applications.

Le seul changement notable sur le block_cache est le retrait de paramÚtres inutilisés dans certaines fonctions, afin de simplifier le code (waddlesplash).

kernel

Une correction de bug sur le blocage des threads avec timeout (par exemple, l’attente d’un mutex ou d’un sĂ©maphore avec un dĂ©lai maximum): dans certains cas, une fonction pouvait retourner B_TIMED_OUT pour d’autres raisons que l’expiration du timer. Ce n’était pas traitĂ© correctement, et le noyau supposait que le timeout avait expirĂ©, alors qu’il s’agissait d’autre chose. Des vĂ©rifications supplĂ©mentaires permettent de traiter ce cas correctement.

Correction de problĂšme sur la programmation des timeouts « absolus temps-rĂ©el ». Comme leur nom l’indique, ils rĂ©fĂ©rencent l’horloge « real time » (qui essaie de suivre l’heure et la date « rĂ©elle », par opposition Ă  l’horloge systĂšme qui est basĂ©e sur l’uptime de la machine, mais garantit de ne jamais faire de saut ou revenir en arriĂšre). Ces timers ne fonctionnaient pas du tout (ou alors, seulement sur un coup de chance), et restaient probablement bloquĂ©s pendant une durĂ©e beaucoup plus longue que demandĂ©. Au passage, nettoyage du code de gestion des timers.

Dans le code de gestion des interruptions: ajout d’assertions pour investiguer un bug dans les addons vmware ou virtualbox.

Correction d’un bug dans l’implĂ©mentation de kqueue qui produisait un blocage au dĂ©marrage de la libevent (qui utilise maintenant kqueue pour Haiku).

Des petites amĂ©liorations de performances: sur l’allocateur mĂ©moire du noyau, sur l’utilisation de verrous dans la gestion de la mĂ©moire virtuelle, des fuites de mĂ©moire dans l’allocation de page, des amĂ©liorations sur la dĂ©tection de rĂ©fĂ©rences devenues invalides (jpelczar + waddlesplash).

Le script de link du noyau refuse maintenant les sections inconnues avec un message d’erreur, au lieu de simplement les ignorer (korli).

Correction du dĂ©compte du temps CPU utilisĂ© par le thread en cours d’exĂ©cution, pour donner des rĂ©sultats plus fiables dans les applications qui affichent l’utilisation CPU (waddlesplash).

Refactorisation du dĂ©compte du temps d’exĂ©cution des appels systĂšmes. Seul le temps passĂ© dans l’exĂ©cution du syscall est prise en compte, sans mesurer la mise en place d’un appel systĂšme et du retour vers l’espace utilisateur (qui ne peuvent de toutes façons pas ĂȘtre mesurĂ©es de façon fiable depuis le noyau). Cela rend l’affichage des durĂ©es d’exĂ©cution dans strace plus facile Ă  interprĂ©ter (waddlesplash).

RĂ©duction de la taille maximale des tampons mĂ©moire pour stocker des dirent Ă  8Kio. La plupart des applications n’utilisent pas un tampon aussi large, et les quelques-unes qui le faisaient ont Ă©tĂ© modifiĂ©es pour rĂ©duire la taille. Cette rĂ©duction permet d’utiliser un allocateur spĂ©cialisĂ© beaucoup plus rapide, ce qui devrait compenser les rares cas oĂč le tampon est trop petit pour rĂ©cupĂ©rer tout le contenu d’un dossier en une seule fois (waddlesplash).

Correction de plusieurs problĂšmes dans le systĂšme de gestion des ressources faibles (qui essaie de libĂ©rer de la mĂ©moire quand il n’y en a plus assez de disponible). Dans certains cas, le systĂšme finit par geler ou dĂ©clencher un kernel panic, alors qu’il devrait toujours ĂȘtre possible de refuser des demandes d’allocation mĂ©moire venant de l’espace utilisateur, et de conserver suffisamment de mĂ©moire libre pour au moins afficher proprement une erreur.

Amélioration de la gestion des mutex (exclusions mutuelles entre threads):

  • Ajout d’assertions pour dĂ©tecter des cas de rĂ©veil d’un thread qui ne devrait pas l’ĂȘtre.
  • Correction d’un problĂšme introduit rĂ©cemment et investiguĂ© Ă  l’aide de ces nouvelles assertions.
  • L’ABI des locks est identiques entre les builds du kernel en version debug ou release, ce qui permet de ne pas avoir besoin de recompiler tous les pilotes dans le mĂȘme mode que le kernel. Les pilotes compilĂ©s en mode release vont dĂ©clencher une erreur de symbole manquant si on essaie de les utiliser avec un noyau en mode debug, dans l’autre sens, il n’y a pas de problĂšme. Auparavant, dans les deux cas on obtenait des crashes ou un gel complet du systĂšme, difficile Ă  investiguer et faisant perdre du temps.
  • Ajout d’assertions dans plusieurs cas pour dĂ©tecter les utilisations incorrectes des rw-locks. Certaines activĂ©es par dĂ©faut, et d’autres uniquement sur demande Ă  la compilation du noyau en raison de coĂ»t de vĂ©rification trop importants.
  • Correction de mauvaises utilisations des rwlocks ainsi dĂ©tectĂ©es.

GĂ©nĂ©ralisation de l’utilisation de fonctions utilitaires partagĂ©es pour la conversion des timespec en durĂ©es en microsecondes. Cela permet aux fonctions concernĂ©es (entre autres kqueue) de bĂ©nĂ©ficier de contrĂŽles de validitĂ© supplĂ©mentaires (waddlesplash).

Ajout d’informations de debug supplĂ©mentaires dans la sortie de la commande slab_object du debugger du noyau.

RĂ©activation de la calibration du TSC Ă  partir d’informations du CPUID lorsque Haiku s’exĂ©cute dans un hyperviseur, comme c’était dĂ©jĂ  le cas lorsqu’il s’exĂ©cute directement sur une machine physique. Le TSC est un timer interne du CPU qui permet des mesures de temps trĂšs rapides (une seule instruction CPU) mais dans une Ă©chelle de temps arbitraire qu’il faut corrĂ©ler avec le « vrai » temps. Cela peut ĂȘtre fait soit Ă  l’aide d’une mesure empirique (mĂ©thode historique), soit Ă  l’aide d’informations sur cette horloge disponibles dans les informations retournĂ©es par l’instruction CPUID.

Affichage de plus de fonctionnalités du CPU reconnues dans les logs de debug pour les processeurs x86 (korli).

Ajout d’un raccourci clavier (Control+D) pour quitter le debugger noyau et reprendre l’exĂ©cution normale si possible (Ă©quivalent Ă  la commande continue ou co) (mmlr).

Le chargement des pilotes de pĂ©riphĂ©riques se fait en prioritĂ© depuis les dossiers non-packaged avant de rechercher les fichiers dans les paquets logiciels, ce qui permet de tester facilement une version modifiĂ©e d’un pilote - sauf si les dossiers non-packaged sont dĂ©sactivĂ©s dans la configuration du noyau (korli).

VFS

Le VFS (virtual file system) est le composant de Haiku qui gĂšre l’accĂšs aux fichiers. Il fait l’intermĂ©diaire entre les appels systĂšmes liĂ©s aux fichiers (open, read, write
) et les systĂšmes de fichiers eux-mĂȘmes. Il implĂ©mente autant que possible ce qui peut ĂȘtre mis en commun entre tous les systĂšmes de fichiers: rĂ©solution de chemins relatifs, vĂ©rification de permissions


Cela rend plus facile l’écriture d’un nouveau systĂšme de fichiers, qui peut alors se concentrer sur les aspects bas niveau et la gestion de ses structures de donnĂ©es.

Ajout de vĂ©rifications d’intĂ©gritĂ©s supplĂ©mentaires dans le VFS pour dĂ©tecter des bugs dans les systĂšmes de fichiers le plus rapidement possible, au lieu d’obtenir un crash du noyau difficile Ă  investiguer un peu plus tard.

Retrait d’un scan du bus SCSI et des pilotes associĂ©s par le device manager pour rĂ©duire un peu le temps de dĂ©marrage.

Correction d’un gros problĂšme dans l’API du noyau IORequest qui aboutissait Ă  une confusion entre la taille totale d’une requĂȘte et l’offset de la derniĂšre donnĂ©e transfĂ©rĂ©e (les transferts ne commençant pas forcĂ©ment Ă  l’offset 0). La consĂ©quence Ă©tait l’écrasement de donnĂ©es dans le cache de fichiers, dĂ©clenchant des crashes du noyau avec des messages d’erreur incomprĂ©hensibles Ă  propos des structures de pages. Correction d’un problĂšme de calcul d’offset qui faisait que certaines opĂ©rations Ă©taient considĂ©rĂ©es comme rĂ©ussies, alors qu’il y avait en fait une erreur.

Correction de problĂšmes de dĂ©comptage de rĂ©fĂ©rences et de gestion du cache Ă  l’interface entre ramfs et VFS, mis en Ă©vidence lors du travail de portage de Firefox.

Ajout d’une acquisition de rĂ©fĂ©rence sur un vnode qui manquait dans le cache de fichiers (waddlesplash).

Améliorations du cache d'entrées, dont en particulier la mise en cache du hash des noms de fichiers, pour éviter des comparaisons de chaßnes de caractÚres inutiles.

Gestion de la mémoire

La gestion de la mĂ©moire virtuelle est une des tĂąches essentielles d’un systĂšme d’exploitation. Elle garantit l’isolation entre les diffĂ©rents processus, permet d’utiliser la mĂ©moire physique le mieux possible (Ă©ventuellement en dĂ©plaçant certaines allocations peu utilisĂ©es vers un espace d’échange sur disque), et permet aussi aux diffĂ©rents processus de se partager des donnĂ©es.

Il s’agit Ă©galement d’un composant trĂšs sollicitĂ©, et dont les performances impactent beaucoup le comportement du systĂšme. Une mauvaise gestion de la mĂ©moire peut fortement ralentir le systĂšme ou le rendre instable.

Ajout d’assertions dans le code gĂ©rant les pages de mĂ©moire, pour essayer d’intercepter ce type de correction plus rapidement si elles se reproduisent.

Dans l’arbre des areas globales : ajout d’assertions pour dĂ©tecter les identifiants d’areas dupliquĂ©s (chaque area doit bien sĂ»r avoir un identifiant unique).

ImplĂ©mentation de PAT (Page Attribute Table) pour les processeurs x86. Les PAT permettent de configurer des zones de mĂ©moires qui peuvent ou ne peuvent pas ĂȘtre mises en cache (complĂštement ou en write-through). Elles remplacent les MTRR en permettant un contrĂŽle plus fin et plus flexible. Au passage, nettoyage de l’implĂ©mentation des MTRR (prĂ©servĂ©e pour les processeurs plus anciens incompatibles avec PAT), ajout de nouvelles commandes dans le debugger noyau. Renommage des constantes B_MTR_* pour indiquer prĂ©cisĂ©ment leur rĂŽle indĂ©pendamment des dĂ©nominations utilisĂ©es dans les registres MTRR qui ne sont pas trĂšs claires (mmlr).

Lorsque le systĂšme utilise PAT, ajout d’assertions pour dĂ©tecter les tentatives d’accĂ©der Ă  la mĂȘme zone de mĂ©moire physique avec des configurations de cache diffĂ©rentes. Elles ne sont pas activĂ©es lorqu'on utilise les MTRR, car ces derniĂšres ne permettent pas une configuration aussi fine (waddlesplash).

Ajout d’informations supplĂ©mentaire dans le message de kernel panic indiquant qu’une page devrait ĂȘtre libre mais qu’elle ne l’est pas. Modification de la commande page du debugger noyau pour rĂ©cupĂ©rer la liste des espaces d’adressage depuis les structures du kernel plutĂŽt que d’itĂ©rer sur tout l’espace d’adressage (ce qui pouvait fonctionner sur un espace 32 bit, mais pas en 64 bit).

Correction du code de « guarded heap » du noyau qui ne compilait plus. Il s’agit d’un allocateur mĂ©moire plus lent mais avec de nombreuses vĂ©rifications d’intĂ©gritĂ© pour dĂ©tecter les dĂ©bordements de tampons, double free, et autres problĂšmes de gestion de la mĂ©moire dans le noyau (kallisti5).

Le fichier swap est automatiquement supprimĂ©, et l’espace disque libĂ©rĂ©, lors de la dĂ©sactivation de la swap. Auparavant, un redĂ©marrage Ă©tait nĂ©cessaire (waddlesplash).

Correction d’un problĂšme dans l’allocation de mĂ©moire « early boot » (avant que l’allocation normale soit mise en place), qui empĂȘchait le dĂ©marrage sur les systĂšmes pouvant gĂ©rer de grandes quantitĂ©s de mĂ©moire (plusieurs centaines de Gio) (waddlesplash).

libroot

La libroot regroupe tous les composants de la librairie standard C (parfois dĂ©coupĂ©e en libc, libm et libpthread pour d’autres systĂšmes). Elle contient en plus un certain nombre d’extensions spĂ©cifiques Ă  Haiku et Ă  BeOS.

Changements effectués par waddlesplash, sauf mentions spécifiques:

Nettoyage de code dans la classe WeakReferenceable, une classe de comptage de références intrusive qui autorise les références "faibles".

Correction de problùmes dans le code d’interfaçage avec ICU pour la conversion de dates (nipos et waddlesplash).

libnetwork

Nettoyage de code de compatibilitĂ© avec BeOS dans la libnetwork, pour faire en sorte qu’il ne soit plus du tout compilĂ© sur les architectures n’offrant pas de compatibilitĂ© avec BeOS.

Compatibilité POSIX

ImplĂ©mentation minimale de mknod et mknodat dans le seul cas spĂ©cifiĂ© par POSIX, qui permet de rĂ©aliser une opĂ©ration Ă©quivalente Ă  mkfifo. La gestion des devices dans Haiku est trĂšs diffĂ©rente de celle utilisĂ©e traditionellement par UNIX, et ne se prĂȘte pas Ă  l’implĂ©mentation des autres utilisations de ces fonctions.

Rectification de l’implĂ©mentation des fonctions *at (par exemple linkat) qui permettent de rĂ©aliser une opĂ©ration Ă  partir d’un descripteur de fichier au lieu d’un path. Dans la libroot, ces fonctions envoyaient la valeur -1 aux appels systĂšmes pour implĂ©menter AT_FDCWD. La valeur de AT_FDCWD a Ă©tĂ© modifiĂ©e pour choisir autre chose que -1 (qui est souvent utilisĂ© pour indiquer une erreur dans le code de retour d’autres fonctions). Les appels systĂšmes acceptent pour l’instant les valeurs -1 et AT_FDCWD, mais rejettent maintenant toutes les autres valeurs nĂ©gatives.

Remplacement d’une partie du code de gestion des flux d’entrĂ©e-sortie par la version de la glibc. La bibliothĂšque libroot est un patchwork d’implĂ©mentations provenant de la glibc, de musl, et de divers BSD, un objectif Ă  terme est d’essayer de se rapprocher d’une de ces implĂ©mentations, mais on ne sait pas encore trop de laquelle. En tout cas, le code des I/O provient majoritairement de la glibc afin d’ĂȘtre trĂšs compatible avec ce qui Ă©tait utilisĂ© dans BeOS.

La fonction gmtime retourne une struct tm avec le champ tm_zone contenant la chaĂźne "GMT" (waddlesplash).

Correction de la conversion des "surrogate pairs" dans la fonction mbrtowc.

Mise en conformitĂ© de l’implĂ©mentation des threads avec POSIX :

  • Ajustement de code d’erreurs retournĂ©s par les fonctions
  • Suppression de la possibilitĂ© de retourner EINTR depuis un rwlock
  • Correction de deadlocks dans les barriers
  • Correction de plusieurs problĂšmes dans l’implĂ©mentation des sĂ©maphores anonymes.

Mise en place systĂ©matique de l’utilisation de _DEFAULT_SOURCE pour protĂ©ger les extensions Ă  la norme POSIX, ce qui permet de les activer automatiquement via l’inclusion de features.h lorsque c’est possible.

Nettoyage de quelques fichiers d’en-tĂȘte, dont en particulier <sys/select.h>, pour Ă©viter de polluer l’espace global avec des macros et des dĂ©finitions en double (waddlesplash).

Prise en compte correcte du drapeau O_NONBLOCK lors de l’ouverture d’un FIFO (korli).

runtime_loader

Le runtime_loader est le composant responsable du chargement en mĂ©moire des exĂ©cutables et du lancement de nouveaux processus. Il rĂ©alise la rĂ©solution des dĂ©pendances et la recherche des bibliothĂšques partagĂ©es nĂ©cessaires pour l’exĂ©cution d’un programme.

Il reçoit des Ă©volutions suite au portage d’applications complexes venues de Linux, qui nĂ©cessitent souvent plusieurs dizaines de bibliothĂšques partagĂ©es.

Correction de problÚmes détectés en testant un portage expérimental et instable de Firefox: crash du runtime_loader dans certains cas si on charge une bibliothÚque (via dlopen ou load_add_on) dont il manque des dépendances.

Retrait de l’option -fno-builtin dans les drapeaux de compilation du runtime_loader, comme cela avait dĂ©jĂ  Ă©tĂ© fait pour la majoritĂ© de la libroot. Cela permet Ă  gcc de remplacer des appels Ă  des fonctions standardisĂ©es par une implĂ©mentation inline plus performante (waddlesplash).

Outils de debug

DĂ©veloppement d’outils pour enregistrer ce qu’il se passe pendant le dĂ©marrage du systĂšme et dĂ©tecter d’éventuels problĂšmes de latence, de 'lock contention', etc. Au passage, correction de divers problĂšmes liĂ©s Ă  ces outils : les barres de dĂ©filement de DebugAnalyzer, les permissions noyau dans transfer_area, etc.

Amélioration de la remontée des valeurs de retour des appels systÚmes vers strace sur les plateformes x86 32-bit.

Pour terminer, un changement rĂ©alisĂ© par mmlr : amĂ©lioration de l’allocateur mĂ©moire "guarded heap" pour le rendre utilisable plus facilement, y compris comme allocateur pour tout le systĂšme. Cet allocateur permet de dĂ©tecter les accĂšs au-delĂ  de la fin d’une zone mĂ©moire allouĂ©e avec malloc(), ainsi que les accĂšs Ă  de la mĂ©moire dĂ©jĂ  libĂ©rĂ©e, mais au prix d’une consommation mĂ©moire nettement plus Ă©levĂ©e qu’un allocateur classique. La disponibilitĂ© d’un espace d’adressage de 64 bits permet de limiter les cas oĂč une adresse mĂ©moire est initialement utilisĂ©e pour une allocation, puis libĂ©rĂ©e et allouĂ©e Ă  nouveau pour autre chose.

Un problĂšme de gestion d’erreur dans l’interfaçage entre le Debugger et le noyau pouvait conduire Ă  un gel complet du systĂšme dans certains cas de plantage du debug_server, en particulier s’il n’y a plus assez de mĂ©moire RAM disponible.

Bootloader

Ajout d’une vĂ©rification manquante pour prendre en compte l’option « BlockedEntries » dans le bootloader. Cette option s’appelait prĂ©cĂ©demment « EntriesBlacklist » mais a Ă©tĂ© renommĂ©e pour utiliser un terme non entachĂ© de racisme. L’ancien nom continue de fonctionner pour ne pas casser les installations existantes, mais n’est plus documentĂ©.

Augmentation de la taille maximum autorisĂ©e pour les allocations « standard » sur la pile. L’allocateur mĂ©moire du bootloader traite sĂ©parĂ©ment les allocations de grande taille, mais ces allocations ne sont pas correctement libĂ©rĂ©es lors du transfert de contrĂŽle vers le noyau, en particulier sur les machines utilisant un BIOS non EFI. Pour l’instant, une correction complĂšte du problĂšme semble compliquĂ©e Ă  mettre en place, mais la modification permet de libĂ©rer de la mĂ©moire allouĂ©e pour l’accĂšs au packagefs (le bootloader a besoin d’y accĂ©der pour trouver le noyau, qui est stockĂ© dans un paquet). Ce changement permet de libĂ©rer plusieurs dizaines de Mio de mĂ©moire, et complĂšte les changements mentionnĂ©s plus haut sur la gestion des paquets aprĂšs dĂ©marrage. Il est possible de configurer Haiku pour fonctionner avec moins de 100Mio de mĂ©moire (waddlesplash).

RĂ©paration de la rĂ©-initialisation des ports sĂ©rie sur le bootloader EFI. Le port sĂ©rie est utilisĂ© Ă  des fins de debug, mais il peut ĂȘtre accĂ©dĂ© de plusieurs façons diffĂ©rentes (en adressant directement le matĂ©riel, ou bien via des services EFI dĂ©diĂ©s). Le bootloader doit passer d’une mĂ©thode Ă  l’autre Ă  diffĂ©rentes Ă©tapes du dĂ©marrage: accĂšs direct au port physique dans les premiĂšres Ă©tapes (en dĂ©tectant s’il est bien prĂ©sent Ă  une adresse standard), accĂšs via les services EFI une fois ceux-ci initialisĂ©s, puis Ă  nouveau accĂšs direct au matĂ©riel aprĂšs l’arrĂȘt des services EFI pour la derniĂšre Ă©tape de passage de contrĂŽle au noyau (cette fois-ci Ă  une adresse qui peut ĂȘtre configurĂ©e dans les options du bootloader et du noyau). Ce fonctionnement ne s’insĂšre pas forcĂ©ment trĂšs bien dans la logique du bootloader, qui n’avait Ă  l’origine pas Ă©tĂ© conçu pour une gestion aussi complexe des entrĂ©es-sorties (VoloDroid).

Réduction de la quantité de logs liés à la mise en place de SMP (gestion de plusieurs processeurs) dans le bootloader pour BIOS (waddlesplash).

Le menu de dĂ©marrage affiche la version (numĂ©ro 'hrev') du paquet systĂšme correspondant Ă  chaque point de restauration disponible, ce qui facilite l’identification des Ă©tats qui correspondent Ă  un changement de version du systĂšme, et pas une simple installation, dĂ©sinstallation ou mise Ă  jour de paquets logiciels (waddlesplash).

Documentation

Haiku Book

Le « Haiku Book » est un projet de documentation des APIs publiques de Haiku. Il doit Ă  terme remplacer le « Be Book », qui documente les APIs de BeOS, mais ne peut pas ĂȘtre mis Ă  jour Ă  cause de se license CC BY-NC-ND. Actuellement, il faut jongler entre ces deux documentations.

La documentation de B_INFINITE_TIMEOUT (constante permettant d’indiquer Ă  certaines fonctions qu’on veut les exĂ©cuter sans timeout, et attendre indĂ©finiment) a Ă©tĂ© mise Ă  jour pour indiquer explicitement que sa valeur numĂ©rique est INT64_MAX (waddlesplash).

Correction de fautes de frappe dans la documentation des API liées aux entrées clavier (drea233).

Haiku Interface Guidelines

Ce document prĂ©sente les bonnes pratiques et conventions pour la conception d’interfaces graphiques fonctionnant avec Haiku.

Ajout d’une section sur la gestion des fichiers rĂ©cemment utilisĂ©s et la façon dont ils peuvent ĂȘtre exposĂ©s aux utilisateurs.

Wiki et documentation interne

Le wiki contient des informations utiles aux développeurs de Haiku.

La documentation « interne" documente le fonctionnement de Haiku en s’adressant principalement aux contributeurs du systĂšme, par opposition aux personnes qui souhaitent seulement dĂ©velopper ou porter des applications.

Mise Ă  jour de la page « release cookbook » indiquant toutes les Ă©tapes Ă  suivre lors de la publication d’une version de Haiku.

Notes d’administration systùme : mise à jour des instructions pour instancier des machines Google Cloud Platform (kallisti5).

SystĂšme de build, environnement de compilation

La compilation d’un systĂšme d’exploitation complet n’est pas chose facile. D’autant plus pour Haiku, qui prĂ©sente les particularitĂ©s suivantes:

  • Utilisation de deux versions de gcc (gcc 2.95.3 et gcc 13) pour la version 32 bit de Haiku, afin d’assurer la compatibilitĂ© binaire avec BeOS,
  • PossibilitĂ© de compilation croisĂ©e depuis Linux, Mac OS et d’autres systĂšmes, ou depuis un hĂŽte Haiku,
  • Compilation d’outils pour la machine hĂŽte de la compilation croisĂ©e, avec si nĂ©cessaire une couche de compatibilitĂ© permettant d’écrire ces outils en utilisant des API et fonctionnalitĂ©s spĂ©cifiques Ă  Haiku,
  • PossibilitĂ© de compiler des applications pour un systĂšme hĂŽte existant (une autre version de Haiku) Ă  des fins de test,
  • Compilation d’un systĂšme complet (noyau, bibliothĂšques, applications, image disque) en une seule opĂ©ration.

Pour ces raisons, l’utilisation d’un systĂšme de build haut niveau (CMake, Meson
) s’avĂšre plutĂŽt complexe. L’utilisation de make ou de ninja directement serait de trop bas niveau. Le choix de Haiku est donc d’utiliser l’outil jam, qui est malheureusement assez peu populaire et tombĂ© Ă  l’abandon dans sa version originale. Haiku maintient un fork de jam qui est concurrent de ceux maintenus par Boost et par Freetype.

Reformatage des fichiers Jamfile pour lister une seule cible par ligne au lieu de les rassembler, cela facilite les rebase et résolutions de conflits (x512).

Mise à jour de paquets en préparation pour la version beta 5: OpenSSL 3, Python 3.10, et autres mises à jour diverses (PulkoMandy, waddlesplash, kallisti5).

Ajout de l’inclusion de <features.h> dans <sched.h>. Le fichier d’en-tĂȘte features.h configure la visibilitĂ© des extensions GNU et BSD aux fichiers d’include standards C et POSIX, en fonction d’options de ligne de commande du compilateur. L’inclusion de ce fichier permet d’utiliser facilement et par dĂ©faut ces extensions (PulkoMandy).

Mise à jour des marque-pages fournis par défaut avec le navigateur WebPositive (waddlesplash).

Ajout des en-tĂȘtes de la bibliothĂšque linprog dans le paquet haiku_devel. Ces en-tĂȘtes sont nĂ©cessaires pour les applications associĂ©es au systĂšme de layout d’interfaces graphiques ALM (korli).

Correction de fautes de frappe dans des commentaires (jmairboeck) et d’un problĂšme de compatibilitĂ© C89 dans un en-tĂȘte systĂšme (waddlesplash).

La taille des images « nightly build » de Haiku est maintenant de 650 Mo, ce qui laisse un peu plus de place disponible pour les utiliser et crĂ©er quelques fichiers (jscipione).

Diverses corrections pour une nouvelle fois essayer de faire fonctionner la compilation de Haiku avec Clang (waddlesplash, oanderso). Les choses en sont toujours au mĂȘme point depuis plusieurs annĂ©es, avec des corrections de temps en temps mais quelques parties du systĂšme qui ne fonctionnent toujours pas correctement.

La compilation du profil « nightly » n’a plus besoin de gĂ©nĂ©rer le paquet haiku_source contenant le code source de Haiku. Ce paquet est inclus uniquement dans les images de releases (pour faciliter le respect strict de la licence GPL de certains composants de Haiku), mais, pour des raisons de dĂ©pendances entre cibles dans le systĂšme de build, il Ă©tait tout de mĂȘme gĂ©nĂ©rĂ© pour les autres profils, ralentissant la compilation (waddlesplash).

Améliorations du script ./configure (jessicah, OscarL et waddlesplash):

  • Le script vĂ©rifie que les options passĂ©es fournies sont valides, et rejette immĂ©diatement les configurations incohĂ©rentes plutĂŽt que de laisser la compilation Ă©chouer bien plus loin.
  • Validation que l’interprĂ©teur Python sĂ©lectionnĂ© existe bien, et uniformisation de la syntaxe utilisĂ©e pour choisir un interprĂ©teur avec la façon dont c’est fait pour d’autres outils.
  • DĂ©tection des options disponibles pour demander Ă  wget de rĂ©-essayer un tĂ©lĂ©chargement en cas d’échec, ce qui permet d’assurer la compatibilitĂ© avec wget2.
  • Utilisation automatique d’une version moderne de GCC pour compiler les outils « hĂŽtes » lors de la compilation Ă  partir d’une machine hĂŽte fonctionnant sous Haiku en version 32 bit, en ignorant le compilateur par dĂ©faut qui est gcc 2 pour des raisons de compatibilitĂ© avec BeOS.

RĂ©organisation du code source de libroot pour dĂ©placer les implĂ©mentations de malloc dans des sous-dossiers sĂ©parĂ©s, et faciliter l’expĂ©rimentation avec d’autres implĂ©mentations de malloc. L’allocateur hoard2 utilisĂ© actuellement n’est pas adaptĂ© aux architectures 64 bits, une tentative a Ă©tĂ© faite il y a quelques annĂ©es avec rpmalloc, mais ce dernier pose des problĂšmes sur les
architectures 32 bits. Des investigations sont en cours avec l’implĂ©mentation de malloc d’OpenBSD.

L’outil de dessin Wonderbrush est maintenant disponible sur toutes les architectures. Historiquement, le code de Wonderbrush n’était pas libre, mais une version gratuite Ă©tait offerte aux utilisateurs de Haiku. Le dĂ©veloppeur principal de Wonderbrush n’est plus trĂšs actif sur le projet et a dĂ©cidĂ© de publier les sources, ce qui a permis de recompiler le programme en version 64 bits et plus tard sur les autres architectures non x86. Mais ces nouvelles versions n’avaient jamais Ă©tĂ© incluses dans Haiku (PulkoMandy).

Nettoyage et centralisation des dĂ©finitions prĂ©processeur pour la compatibilitĂ© avec BeOS. DĂ©sactivation de la compatibilitĂ© avec BeOS dans le noyau, la compatibilitĂ© avec les pilotes et modules noyau de BeOS n’étant plus assurĂ©e depuis quelque temps dans Haiku.

Suppression de définitions de rÚgles obsolÚtes et inutilisées dans le Jamfile permettant de construire le fichier package_repo (CodeforEvolution).

Remise en service du test DiskDeviceManagerTest qui ne compilait plus (waddlesplash).

ARM & PowerPC

Actuellement, Haiku est disponible officiellement pour les architectures x86 32 et 64 bits. Une version RISC-V 64 bits expĂ©rimentale est Ă©galement disponible mais pas encore totalement intĂ©grĂ©e dans le dĂ©pĂŽt de code principal, des discussions sont en cours sur la bonne façon de faire certains changements nĂ©cessaires. Les versions ARM (32 et 64 bits) et PowerPC sont les prochaines cibles sur la liste. La premiĂšre, car c’est une architecture trĂšs populaire, la deuxiĂšme plutĂŽt pour des raisons historiques : c’est l’une des architectures sur lesquelles fonctionne BeOS.

Renommage de structures qui Ă©taient initialement spĂ©cifiques Ă  l’architecture x86, mais qui sont finalement utilisĂ©es Ă©galement sur d’autres CPU sans nĂ©cessiter de changements (waddlesplash).

RĂ©paration de la console de texte du chargeur de dĂ©marrage OpenFirmware qui Ă©tait cassĂ©e depuis l’adaptation pour OpenBOOT sur les machines SPARC (zeldakatze).

Sur ARM, utilisation de la bonne instruction CPU pour mettre le processeur en veille quand il n’y a rien à faire (archeYR).

oanderso continue le travail sur le portage ARM64:

  • Correction de plusieurs problĂšmes liĂ©s Ă  la gestion du cache et de la MMU dans le bootloader, ce qui permet de dĂ©marrer le noyau dans une machine virtuelle sur un hĂŽte Apple M1.
  • Correction de l’implĂ©mentation des timers dans le kernel qui ne fonctionnait pas dans les environnements virtualisĂ©s.
  • Quelques avancĂ©es sur la gestion de la MMU : ImplĂ©mentation de la table de translation de la mĂ©moire virtuelle, du traitement des exceptions matĂ©rielles (dĂ©fauts de page), des TLBs.
  • Synchronisation du cache d’instructions.
  • Correction de problĂšmes de double lock.

Ajout de messages sur le port sĂ©rie traçant l’exĂ©cution de mĂ©thodes spĂ©cifiques Ă  une architecture qui ne sont pas encore implĂ©mentĂ©es. Ceci permet de dĂ©tecter facilement quelle est la prochaine fonction Ă  implĂ©menter (waddlesplash).

Nettoyage et documentation du fichier ArchitectureRules pour simplifier la configuration des options en ligne de commande du compilateur (qui doit savoir traiter deux versions de gcc et clang) (waddlesplash).

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans - Haiku R1 bĂȘta 5 (partie 3 : documentation, finances et GSOC)

Les deux parties précédentes ont présenté les principales évolutions dans le code de Haiku. Mais le code ne fait pas tout.

Cette troisiĂšme (et derniĂšre) partie prĂ©sente les nouveautĂ©s dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent Ă  Haiku d’employer un dĂ©veloppeur Ă  plein temps de façon durable.

Enfin, elle présente la participation au Google Summer of Code et les travaux réalisés par les cinq étudiants encadrés par Haiku cette année.

Sommaire

Documentation

La documentation de Haiku se dĂ©coupe en 3 parties principales : un manuel de l’utilisateur, une documentation d’API, et une documentation interne pour les dĂ©veloppeurs qui travaillent sur les composants du systĂšme.

Ces documents sont complĂ©tĂ©s par de nombreuses pages et articles sur le site Internet, et deux livres pour apprendre Ă  programmer en C++ avec Haiku, ou encore un document de rĂ©fĂ©rence pour la conception d’interfaces graphiques et un autre pour le style graphique des icĂŽnes.

Documentation d’API

La documentation d’API de BeOS Ă©tait assez complĂšte et de bonne qualitĂ©. L’entreprise Access Co Ltd qui a hĂ©ritĂ© de la propriĂ©tĂ© intellectuelle de BeOS a autorisĂ© le projet Haiku Ă  la rĂ©utiliser et Ă  la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas ĂȘtre mise Ă  jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutĂ©es par Haiku ou les diffĂ©rences entre les deux systĂšmes.

Il est donc nĂ©cessaire de rĂ©Ă©crire une nouvelle documentation Ă  partir de zĂ©ro. Ce travail est assez ingrat lorsqu’il s’agit de re-dĂ©crire ce qui est dĂ©jĂ  trĂšs bien expliquĂ© dans la documentation existante. La nouvelle documentation a donc tendance Ă  se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers .h, et des exemples de code d’applications existantes pour dĂ©couvrir toutes les possibilitĂ©s offertes.

Il ne semble pas utile de lister chaque fonction ou mĂ©thode qui a Ă©tĂ© documentĂ©e. On peut mentionner une page d’explications sur la bibliothĂšque C standard, comprenant des liens vers les spĂ©cifications POSIX qui documentent dĂ©jĂ  la plupart des choses, et quelques dĂ©tails sur les diffĂ©rences avec d’autres systĂšmes.

Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exĂ©cutant dans le noyau.

Documentation interne

La documentation interne Ă©tait Ă  l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dĂ©pĂŽt Git de Haiku. Depuis 2021, ces fichiers ont Ă©tĂ© rassemblĂ©s et organisĂ©s Ă  l’aide de Sphinx, qui permet de mettre Ă  disposition une version navigable en HTML et de donner une meilleure visibilitĂ© Ă  ces documents.

D’autres pages sont petit Ă  petit migrĂ©es depuis le site web principal de Haiku, qui n’est pas un trĂšs bon support pour de la documentation, et bĂ©nĂ©ficiera un jour d’une refonte pour ĂȘtre plus tournĂ© vers les utilisateurs que vers les dĂ©veloppeurs.

Quelques nouvelles pages ajoutées cette année:

  • Une documentation sur l’utilisation de divers outils de complĂ©tion de code automatique avec le code source de Haiku
  • Une page prĂ©sentant l’organisation du code source et les principaux dossiers et sous-dossiers
  • La documentation de l’outil rc utilisĂ© pour compiler les « resources » attachĂ©es aux exĂ©cutables a Ă©tĂ© intĂ©grĂ©e
  • Le systĂšme de fichier FAT a reçu Ă©galement une page de documentation Ă  l’occasion de sa rĂ©Ă©criture

Un point sur le financement

L’association Haiku inc qui gĂšre le compte en banque de Haiku publie chaque annĂ©e un rapport financier.

Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit Ă©galement une compensation financiĂšre de Google pour le temps passĂ© Ă  encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette annĂ©e est de 3 300$.

Les plateformes de don les plus utilisĂ©es sont Paypal et Github sponsor. Ce dernier est recommandĂ© car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donnĂ© arrive donc sur le compte de Haiku. Tous les autres opĂ©rateurs ont un coĂ»t, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mĂ©lange des deux.

En 2023, l’association a reçu 25 422$ de dons et a dĂ©pensĂ© 24 750$. Elle dispose d’une rĂ©serve confortable de 100 000$ (accumulĂ©s avant 2021, alors qu’il n’y avait pas de dĂ©veloppeur salariĂ©) ainsi que d’environ 150 000$ en cryptomonnaies.

Les dons en cryptomonnaies sont pour l’instant bloquĂ©s sur un compte Coinbase suite Ă  des problĂšmes administratifs (le compte n’est pas correctement dĂ©clarĂ© comme appartenant Ă  une association, il faudrait donc payer un impĂŽt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour rĂ©gler ce problĂšme.

Du cĂŽtĂ© des dĂ©penses, le poste le plus important est le paiement de 21 000$ Ă  Waddlesplash, dĂ©veloppeur employĂ© par Haiku inc pour faire avancer le projet Haiku. Il travaille Ă  temps partiel et avec un salaire trĂšs bas par rapport au marchĂ©, comme cela a Ă©tĂ© fait pour les prĂ©cĂ©dents contrats entre Haiku inc et d’autres dĂ©veloppeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi Ă  plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme Ă  condition de puiser dans les rĂ©serves de trĂ©sorerie).

Le reste des dĂ©penses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intĂ©gration continue, hĂ©bergement cloud pour les dĂ©pĂŽts de paquets) pour environ 3 000$.

Il faut enfin compter environ 500$ de frais Paypal, puis quelques dĂ©penses administratives (dĂ©claration de changement d’adresse de l’association, dĂ©claration d’embauche) pour des montants nĂ©gligeables (moins de 10$ au total).

En 2024, l’objectif fixĂ© en janvier Ă©tait de rĂ©colter 20 000$ de dons supplĂ©mentaires. Cet objectif a Ă©tĂ© atteint dĂšs le mois de juillet, et a donc Ă©tĂ© rĂ©visĂ© pour tenter d’atteindre les 30 000$. Cela permettra de rĂ©munĂ©rer Waddlesplash pour un plus grand nombre d’heures cette annĂ©e, ou bien d’envisager l’embauche d’une deuxiĂšme personne si un ou une candidate se prĂ©sente parmi les personnes contribuant au projet (l’embauche d’une personne extĂ©rieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rĂ©munĂ©ration raisonnable).

Google Summer of Code

Haiku participe au Google Summer of Code depuis 2007. Il s’agit d’un programme oĂč des Ă©tudiants (et d’autres participants pas forcĂ©ment Ă©tudiants, ces derniĂšres annĂ©es) sont payĂ©s par Google pendant deux mois pour dĂ©couvrir la contribution Ă  des projets de logiciels libres.

Ce programme a Ă©tĂ© montĂ© par « l’Open source program office » de Google. Leur intĂ©rĂȘt est de dĂ©fendre leur image d’entreprise sympathique (bien mise Ă  mal ces derniĂšres annĂ©es, c’est devenu un gĂ©ant de la publicitĂ© en ligne et de l’aspiration des donnĂ©es personnelles), et de contribuer Ă  la richesse d’un Ă©cosystĂšme de logiciels libres dont ils bĂ©nĂ©ficient beaucoup. Cela permet aussi d’encourager des personnes Ă  s’essayer au dĂ©veloppement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothĂ©tiques ou trĂšs indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars Ă  ce programme.

Une Ă©quipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste Â«â€Żd’idĂ©es » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilitĂ© de choisir parmi les candidats qui ont rĂ©pondu Ă  cette offre (en respectant les critĂšres de non-discrimination imposĂ©es par Google ainsi que les embargos imposĂ©s par les USA), et d’assurer l’encadrement des personnes sĂ©lectionnĂ©es. Google rĂ©munĂšre les participants, et dĂ©dommage les projets participants pour le temps investi.

Cette année les développeurs de Haiku encadrent cinq participants :

Calisto Mathias — Re-design de la fenĂȘtre de recherche de fichiers

Le systĂšme de fichier BFS utilisĂ© par Haiku permet l’exĂ©cution de requĂȘtes (comme une base de donnĂ©es) exploitant les attributs Ă©tendus des fichiers, qui peuvent ĂȘtre indexĂ©s.

Ce systĂšme permet de faire beaucoup de choses, et la fenĂȘtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface rĂ©sultante est trop complexe, et peu de personnes prennent le temps de concevoir des requĂȘtes amĂ©liorant leur façon de travailler, se cantonnant aux quelques exemples fournis.

L’objectif de ce projet est de refondre l’interface de cette fenĂȘtre pour obtenir quelque chose de plus intuitif, et Ă©galement d’afficher en temps rĂ©el les rĂ©sultats de la requĂȘte dĂšs qu’elle est modifiĂ©e, pour encourager les utilisateurs Ă  expĂ©rimenter avec des requĂȘtes plus complexes.

Daniel Martin — Virtualisation matĂ©rielle accĂ©lĂ©rĂ©e avec NVMM

Haiku n’est pas encore parfait, et certaines tĂąches nĂ©cessitent encore l’utilisation d’autres systĂšmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle.

L’objectif de ce projet est de permettre d’utiliser Haiku comme systĂšme principal, et de lancer les autres systĂšmes dans des machines virtuelles. Cela sera rĂ©alisĂ© Ă  l’aide d’un portage de NVMM, qui a Ă©tĂ© dĂ©veloppĂ© Ă  l’origine par NetBSD et Dragonfly BSD. Cette bibliothĂšque a l’avantage d’ĂȘtre bien documentĂ©e et conçue pour faciliter son adaptation vers d’autres systĂšmes.

NVMM sera complĂ©tĂ©e par l’utilisation de QEMU qui pourra fournir un « front-end » Ă  cette mĂ©canique.

Diego Roux — Pilote pour les cartes sons virtuelles VirtIO

Pour les personnes utilisant Haiku dans une machine virtuelle, il est intĂ©ressant d’utiliser autant que possible la famille de pĂ©riphĂ©riques VirtIO.

Il s’agit de pĂ©riphĂ©riques virtuels conçus sans s’inspirer de matĂ©riel existant, et plutĂŽt pour avoir l’interface la plus simple possible entre la machine virtualisĂ©e et son hĂŽte.

Haiku dispose dĂ©jĂ  d’un jeu de pilote Virtio relativement complet (rĂ©seau, stockage de masse, affichage graphique). Le but de ce projet est de complĂ©ter cet ensemble avec un pilote pour les cartes son VirtIO.

trungnt2910 — Portage de GDB

Haiku dispose de son propre dĂ©bugger (appelĂ© Debugger, de façon assez peu originale). Ce dernier prĂ©sente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitĂ©e. Il souffre Ă©galement de quelques problĂšmes de performances et d’un manque de prise en charge des fichiers exĂ©cutables et bibliothĂšques compilĂ©s avec autre chose que GCC. Il est Ă©galement incapable de faire du debug Ă  distance ou de s’intĂ©grer dans une interface graphique existante (par exemple au sein d’un IDE).

L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version trĂšs ancienne Ă©tait utilisĂ©e avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a Ă©tĂ© entiĂšrement rĂ©Ă©crit pour s’adapter aux versions modernes de GDB, et plusieurs Ă©volutions et corrections ont Ă©tĂ© intĂ©grĂ©es dans le systĂšme de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement crĂ©Ă©s afin que le debugger puisse les intercepter).

Zardshard — Migration du navigateur web WebPositive vers WebKit2

Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exĂ©cute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nĂ©cessaires pour les navigateurs web modernes (que ce soit en termes de sĂ©curitĂ©, ou en termes de fiabilitĂ©).

L’objectif de ce projet est de reprendre les travaux dĂ©jĂ  entamĂ©s en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bĂ©nĂ©ficier d’une sĂ©paration entre l’interface graphique, la communication rĂ©seau, et le rendu HTML/CSS/JavaScript dans des applications sĂ©parĂ©es. Ainsi, un crash d’un de ces composants peut ĂȘtre rĂ©cupĂ©rĂ© de façon transparente sans faire disparaĂźtre toute l’application (et les donnĂ©es non enregistrĂ©es de l’utilisateur avec).

Le projet est Ă©galement en bonne voie, un navigateur de test permet dĂ©jĂ  d’afficher quelques pages ce qui montre que les bases sont en place. Il reste Ă  rĂ©gler de nombreux problĂšmes de rendu de texte, ainsi qu’à implĂ©menter la gestion des entrĂ©es (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans - Haiku R1 bĂȘta 5 (partie 2 : le noyau)

21 septembre 2024 Ă  04:02

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

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 6me 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 12me 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.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans - Haiku R1 bĂȘta 5 (partie 1 : applications)

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).

Le projet Haiku (au dĂ©part nommĂ© OpenBeOS) a dĂ©marrĂ© officiellement le 18 aoĂ»t 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y). Cet anniversaire est l’occasion de faire un point sur les dĂ©veloppements de l’annĂ©e dans Haiku et ce qui est en prĂ©paration.

La dĂ©pĂȘche a Ă©tĂ© un peu retardĂ©e cette annĂ©e, pour ĂȘtre synchronisĂ©e avec la version R1 bĂȘta 5 de Haiku, publiĂ©e le vendredi 13 septembre 2024.

Le projet emploie un dĂ©veloppeur presque Ă  plein temps depuis 2021 et le reste de l’équipe contribue bĂ©nĂ©volement. La derniĂšre version bĂȘta a Ă©tĂ© publiĂ©e fin 2023 et la BĂȘta 5 est dĂ©sormais disponible : l’occasion de revenir en trois parties sur ce que propose Haiku, d’abord des applications, un noyau et des amĂ©liorations de la documentation.

Sommaire

PrĂšs de 350 tickets ont Ă©tĂ© clos dans le cadre du travail sur la version R1 bĂȘta 5. Il y a bien sĂ»r de trĂšs nombreuses corrections de bugs, qui ne seront pas listĂ©es dans cet article. On se concentrera plutĂŽt sur les nouveautĂ©s, sauf dans les cas oĂč la correction est vraiment importante ou permet d’ouvrir de nouvelles possibilitĂ©s d’utilisation.

Applications

Haiku est un systĂšme d’exploitation complet, fourni avec un certain nombre d’applications permettant d’accomplir les tĂąches les plus courantes. En plus de ces applications de base, le gestionnaire de paquets HaikuDepot, alimentĂ© principalement par le travail du projet HaikuPorts, apporte Ă  la fois des applications portĂ©es depuis d’autres systĂšmes et des applications dĂ©veloppĂ©es spĂ©cifiquement pour Haiku.

De façon gĂ©nĂ©rale, on trouve cette annĂ©e dans les applications de Haiku des amĂ©liorations sur le rendu des nombres, l’utilisation d’un symbole de multiplication Ă  la place d’une lettre x lĂ  oĂč c’est pertinent, et de nombreuses petites corrections et amĂ©liorations sur la mise en page des fenĂȘtres, des corrections de problĂšmes de traduction et ainsi de suite.

AboutSystem

AboutSystem est la fenĂȘtre d’information sur le systĂšme Haiku. Elle fournit quelques informations sur la machine sur laquelle le systĂšme fonctionne (quantitĂ© de RAM, marque et modĂšle du CPU, uptime) ainsi que les noms des dĂ©veloppeurs et autres logiciels libres ayant participĂ© au dĂ©veloppement de Haiku.

Cette application reçoit tout d’abord une mise Ă  jour cosmĂ©tique : si le systĂšme est configurĂ© en « mode sombre », le logo Haiku correspondant (avec un lettrage blanc et des dĂ©gradĂ©s de couleurs un peu diffĂ©rents) sera utilisĂ©. Sinon, ce sera le logo avec lettrage noir.

AboutSystem en mode clair
AboutSystem en mode sombre

Elle reçoit Ă©galement quelques mises Ă  jour de contenu : en plus de l’ajout de quelques nouveaux contributeurs qui ont rejoint le projet, on trouvera maintenant un lien vers la page web permettant de faire un don Ă  Haiku. Plusieurs liens vers des bibliothĂšques tierces utilisĂ©es dans Haiku, qui ne fonctionnaient plus, ont Ă©tĂ© soit supprimĂ©s, soit remplacĂ©s par des liens mis Ă  jour.

Enfin, il est dĂ©sormais possible d’utiliser AboutSystem comme un « rĂ©plicant », c’est-Ă -dire de l’installer directement sur le bureau pour avoir en permanence sous les yeux les statistiques sur l’utilisation mĂ©moire et l’uptime ainsi que le numĂ©ro de build de Haiku en cours d’exĂ©cution (ce qui peut ĂȘtre utile par exemple lorsqu’on lance beaucoup de machines virtuelles avec des versions diffĂ©rentes de Haiku pour comparer un comportement, ou si on veut stocker des captures d’écran de plusieurs versions et s’y retrouver facilement).

CharacterMap

L’application « table de caractĂšres » permet d’étudier de prĂšs les diffĂ©rents glyphes et symboles prĂ©sents dans une police de caractĂšres. En principe, elle permet de choisir une police spĂ©cifique, mais le serveur graphique de Haiku substitue automatiquement une autre police si on lui demande d’afficher un caractĂšre qui n’est pas disponible dans la police demandĂ©e.

Cela peut ĂȘtre gĂȘnant dans certains contextes, par exemple si on envisage d’embarquer une police dans un fichier PDF, il est difficile de savoir quelle police contient vraiment les caractĂšres qu’on veut utiliser.

L’application a Ă©tĂ© amĂ©liorĂ©e pour traiter ce cas et affiche maintenant ces caractĂšres en grisĂ©.

CharacterMap affichant des caractĂšres manquants

CodyCam

CodyCam est une application permettant de tester une webcam et de l’utiliser pour envoyer pĂ©riodiquement des images vers un serveur HTTP.

L’évolution principale a Ă©tĂ© la mise Ă  jour de l’icĂŽne de l’application. L’utilitĂ© de CodyCam est limitĂ©e par le manque de pilotes : il faudra soit trouver une webcam Sonix du dĂ©but des annĂ©es 90, seul modĂšle USB Ă  disposer d’un pilote fonctionnel, soit utiliser un ordiphone Android Ă©quipĂ© d’un logiciel permettant de le transformer en camĂ©ra IP (ou encore une vraie camĂ©ra IP).

Le pilote pour les WebCams UVC — standard utilisĂ© pour les camĂ©ras USB modernes — n’est pas encore au point et n’est pas inclus dans les versions publiĂ©es de Haiku.

Debugger

Debugger est, comme son nom l’indique, le debugger de Haiku. Il est dĂ©veloppĂ© spĂ©cifiquement pour le projet sans s’appuyer sur les outils existants (gdb ou lldb). Il dispose Ă  la fois d’une interface graphique et d’une interface en ligne de commande, plus limitĂ©e. Cette derniĂšre est surtout utilisĂ©e pour investiguer des problĂšmes dans les composants de Haiku qui sont nĂ©cessaires pour l’utilisation d’une application graphique : app_server, input_server ou encore registrar.

La version en ligne de commande a reçu quelques petites amĂ©liorations, mais la principale nouveautĂ© est la prise en charge des formats DWARF-4 et DWARF-5 pour les informations de debug. Cela permet de charger les informations gĂ©nĂ©rĂ©es par les versions modernes de GCC, sans avoir besoin de forcer la gĂ©nĂ©ration d’une version plus ancienne du format DWARF.

Le dĂ©sassembleur udis86, qui n’est plus maintenu et ne reconnaĂźt pas certaines instructions ajoutĂ©es rĂ©cemment dans les processeurs x86, a Ă©tĂ© remplacĂ© par Zydis.

Enfin, un bug assez gĂȘnant a Ă©tĂ© corrigé : si une instance de Debugger Ă©tait dĂ©jĂ  en train de dĂ©bugger une application et qu’une deuxiĂšme application venait Ă  planter, il n’était pas possible d’attacher une deuxiĂšme instance de Debugger Ă  cette application. Les problĂšmes impliquant plusieurs processus pouvaient donc ĂȘtre un peu compliquĂ©s Ă  investiguer. C’est maintenant rĂ©solu.

Deskbar

L’application DeskBar fournit la « barre des tĂąches » de Haiku. Elle permet de naviguer entre les fenĂȘtres et applications ouvertes, de lancer de nouvelles applications via un menu (similaire au « menu dĂ©marrer » de Windows), ou encore d’afficher une horloge et des icĂŽnes fournis par d’autres applications (sous forme de rĂ©plicants).

Elle fait partie, avec le Tracker, des applications qui ont Ă©tĂ© publiĂ©es sous license libre lors de l’abandon de BeOS par Be Inc.

Quelques changements dans la DeskBar :

  • Tous les menus utilisent maintenant la police « menu » choisie dans les prĂ©fĂ©rences d’apparence du systĂšme. Auparavant, la police « menu » et la police « plain » Ă©taient mĂ©langĂ©es. Ces deux polices Ă©tant identiques dans la configuration par dĂ©faut, le problĂšme n’avait pas Ă©tĂ© repĂ©rĂ©.
  • Si un nom de fenĂȘtre est tronquĂ© dans la liste des fenĂȘtres, le nom complet peut ĂȘtre affichĂ© dans une infobulle.
  • L’icĂŽne pour les fenĂȘtres dans la DeskBar a Ă©tĂ© remplacĂ©e. La nouvelle icĂŽne indique plus clairement si une fenĂȘtre se trouve dans un autre bureau virtuel (dans ce cas, activer cette fenĂȘtre provoquera un changement de bureau).

GLTeapot

GLTeapot est une application permettant de tester le rendu OpenGL, en affichant un modĂšle 3D de la thĂ©iĂšre de l’Utah.

En plus de la thĂ©iĂšre, cette application affiche un compteur du nombre d’images affichĂ©es par secondes. Bien que les chiffres affichĂ©s ne soient pas du tout reprĂ©sentatifs des performances d’un rendu 3D rĂ©aliste, certains utilisateurs insistent lourdement pour pouvoir faire le concours de gros chiffres de nombre d’images par seconde.

Il est donc Ă  nouveau possible de dĂ©sactiver la synchronisation sur le rafraĂźchissement de l’écran, et demander au processeur de rĂ©afficher la thĂ©iĂšre plusieurs centaines de fois par seconde, bien que l’écran soit incapable de suivre le rythme. Par dĂ©faut, la synchronisation est activĂ©e et le rafraĂźchissement ne dĂ©passera jamais 60 FPS, si toutefois le pilote graphique implĂ©mente les fonctions de synchronisation nĂ©cessaires.

HaikuDepot

HaikuDepot est un hybride entre un gestionnaire de paquets et un magasin d’applications.

Il se compose d’un serveur (dĂ©veloppĂ© en Java) fournissant une API REST et permettant de collecter les informations sur les applications (icĂŽnes, captures d’écrans, catĂ©gories, votes et revues des utilisateurs, choix de la rĂ©daction pour les applications mises en avant
), d’un frontend web minimaliste et d’une application native C++ permettant d’afficher ces donnĂ©es.

La principale nouveautĂ© est l’intĂ©gration du systĂšme de single-sign-on (SSO) permettant d’utiliser un compte utilisateur commun avec d’autres services en ligne de Haiku. Actuellement, l’outil de revue de code Gerrit
utilise ce mĂȘme compte, mais ce n’est pas encore le cas pour Trac (outil de suivi des bugs) ni pour le forum. Ce sera mis en place plus tard.

De façon peut-ĂȘtre moins visible, mais pas moins importante, le code C++ de l’application a reçu de nombreuses amĂ©liorations et optimisations « sous le capot », rendant l’application plus rapide et plus fiable, mais qui sont un peu difficiles Ă  rĂ©sumer dans le cadre de cette dĂ©pĂȘche.

Enfin, l’apparence de l’application a Ă©tĂ© lĂ©gĂšrement retravaillĂ©e pour mieux s’adapter aux Ă©crans Ă  haute dĂ©finition (ce qui nĂ©cessite d’avoir des marges et espacements de taille dynamique en fonction de la taille de texte choisie par l’utilisateur).

Icon-O-Matic

Capture d’écran de l’éditeur d’icĂŽnes

Icon-O-Matic est un Ă©diteur d’icĂŽnes. Il permet d’exporter les fichiers au format HVIF, un format vectoriel compact qui permet de stocker les icĂŽnes dans l’inode d’en-tĂȘte des fichiers pour un chargement et un affichage rapide.

Cette application a bĂ©nĂ©ficiĂ© du travail de Zardshard pendant le Google Summer of Code 2023, elle a donc reçu plusieurs Ă©volutions et corrections importantes (dont certaines sont mentionnĂ©es dans la dĂ©pĂȘche anniversaire de l’annĂ©e derniĂšre).

Citons en particulier l’ajout d’un nouveau type de transformation, « perspective », qui permet de facilement dĂ©former un ensemble de chemins vectoriels selon une projection de perspective, ce qui est assez utile pour concevoir plus facilement une icĂŽne avec un aspect tridimensionnel (bien qu’en pratique l’apparence habituelle des icĂŽnes de Haiku soit un intermĂ©diaire entre une projection perspective et une vue isomĂ©trique, ne se prĂȘtant pas forcĂ©ment Ă  l’utilisation de cette opĂ©ration de transformation purement mathĂ©matique).

Une autre petite amĂ©lioration est l’ajout d’une vĂ©rification pour empĂȘcher la fenĂȘtre de Icon-O-Matic de se positionner en dehors de l’écran, par exemple si on a dĂ©placĂ© la fenĂȘtre vers le bas de l’écran, enregistrĂ© cette position, puis relancĂ© l’application dans une rĂ©solution d’écran plus rĂ©duite. Dans ce cas, la fenĂȘtre sera automatiquement ramenĂ©e dans la zone visible de l’affichage.

Magnify

L’application Magnify permet d’afficher une vue zoomĂ©e d’une partie de l’écran. Elle peut servir pour amĂ©liorer l’accessibilitĂ© (mais n’est pas idĂ©ale pour cet usage), mais aussi pour les dĂ©veloppeurs d’interfaces graphiques qui ont parfois besoin de compter les pixels pour s’assurer que leurs fenĂȘtres sont bien construites.

En plus de l’affichage zoomĂ©, l’application permet d’afficher l’encodage RGB de la couleur d’un pixel, ou encore de placer des « rĂšgles » permettant de vĂ©rifier l’alignement des objets. Ces derniĂšres ont reçu une petite mise Ă  jour, avec une amĂ©lioration de l’affichage de leur largeur et hauteur pour les rendre plus lisibles.

Magnify avec une 'rĂšgle'

MediaPlayer

L’affichage des sous-titres ne fonctionnait pas correctement, il manquait une partie du texte. C’est maintenant corrigĂ©.

PowerStatus

Capture d’écran de PowerStatus: fenĂȘtre principale et icĂŽne de la DeskBar avec son menu

L’application PowerStatus permet de surveiller l’état de la batterie pour les ordinateurs qui en disposent.

Elle a reçu plusieurs améliorations importantes :

Une notification a Ă©tĂ© ajoutĂ©e pour un niveau de dĂ©charge trĂšs faible (en plus du niveau faible dĂ©jĂ  prĂ©sent). Ces deux niveaux peuvent ĂȘtre paramĂ©trĂ©s Ă  un pourcentage choisi de dĂ©charge de la batterie, et associĂ© Ă  des sons d’alerte spĂ©cifiques. Avant ces changements, il Ă©tait facile de ne pas voir le message d’alerte (affichĂ© seulement pendant quelques secondes) ou de se dire qu’avec 15% de batterie on a encore le temps de faire plein de trucs, puis se retrouver un peu plus tard avec une batterie vide sans autre avertissement.

L’état « not charging » est maintenant dĂ©tectĂ© et correctement affichĂ©, pour une batterie au repos : ni en train de se charger, ni en train d’alimenter la machine. C’est en particulier le cas d’une batterie dĂ©jĂ  chargĂ©e Ă  100%, si la machine reste connectĂ©e au rĂ©seau Ă©lectrique.

L’icĂŽne de statut de la batterie s’installe automatiquement dans la DeskBar au premier dĂ©marrage de Haiku sur les machines disposant d’une batterie.

Le rĂ©glage du mode « performance » ou « économie d’énergie" est enregistrĂ© et rĂ©-appliquĂ© lors des prochains dĂ©marrages (ces modes configurent l’ordonnanceur du noyau pour exĂ©cuter un maximum de tĂąches sur tous les cƓurs du processeur, ou bien au contraire pour essayer de garder ces cƓurs en veille autant que possible s’ils ne sont pas nĂ©cessaires).

SerialConnect

SerialConnect est une application de terminal série, utile principalement aux développeurs de systÚmes embarqués et autres gadgets électroniques.

Elle est encore en cours de dĂ©veloppement et propose pour l’instant les fonctions les plus basiques. Il est maintenant possible de coller du texte depuis le presse-papier pour l’envoyer sur un port sĂ©rie, ce qui est pratique si on veut envoyer plusieurs fois la mĂȘme sĂ©quence de commandes.

ShowImage

ShowImage est la visionneuse d’images de Haiku. Elle utilise les traducteurs, des greffons avec une API standardisĂ©e qui permettent de convertir diffĂ©rents formats de fichiers entre eux.

L’interface graphique de ShowImage a Ă©tĂ© mise Ă  jour pour utiliser le « layout system ». Historiquement, dans BeOS, tous les Ă©lĂ©ments des interfaces graphiques devaient ĂȘtre positionnĂ©s manuellement avec des coordonnĂ©es en pixels, ce qui est pĂ©nible Ă  faire, surtout si on doit traiter tous les cas (polices de caractĂšres de diffĂ©rentes tailles, remplacement des textes lors de traductions, utilisation de thĂšme d’interfaces diffĂ©rents), et aussi lors d’évolution de l’application (si on veut insĂ©rer un Ă©lĂ©ment en plein milieu, il faut souvent dĂ©caler tout ce qui se trouve autour).

Le « layout system » fournit un ensemble d’outils pour automatiser ce travail, soit Ă  l’aide d’élĂ©ments prĂ©dĂ©finis (grilles, groupes, « cartes » superposĂ©es), soit Ă  l’aide d’un systĂšme de dĂ©finition de contraintes et de programmation linĂ©aire.

D’autre part, ShowImage dispose maintenant d’un menu permettant d’ouvrir l’image affichĂ©e dans un Ă©diteur d’images.

Terminal

Le Terminal de Haiku permet d’exĂ©cuter un shell (c’est bash par dĂ©faut) et toutes les applications conçues pour un affichage en console.

Les principaux changements cette annĂ©e sont la correction d’un problĂšme sur la configuration des couleurs utilisĂ©es par le Terminal (il y avait un mĂ©lange entre le nom anglais et le nom traduit des couleurs, empĂȘchant d’enregistrer et de relire correctement le fichier de configuration), ainsi que des modifications sur les raccourcis clavier utilisĂ©s par le Terminal lui-mĂȘme (en particulier pour naviguer entre plusieurs onglets) qui entraient en conflit avec ceux utilisĂ©s par les applications lancĂ©es dans le terminal.

Le terminal est Ă©galement capable de traiter les « bracketed paste », c’est-Ă -dire que les applications en console sont informĂ©es que des caractĂšres en entrĂ©e proviennent du presse-papier. Cela permet par exemple Ă  bash de ne pas exĂ©cuter directement des commandes qui sont collĂ©es, mais de les mettre en surbrillance et d’attendre que l’utilisateur valide cette saisie.

D’un point de vue plus bas niveau, les pilotes TTY utilisĂ©s pour les ports sĂ©rie et pour le Terminal, qui Ă©taient indĂ©pendants, ont Ă©tĂ© unifiĂ©s afin d’éviter de devoir corriger tous les bugs deux fois dans deux versions du code presque identiques.

Tracker

Tracker est le navigateur de fichiers de Haiku. Tout comme la DeskBar, il fait partie des quelques rares morceaux de BeOS qui ont Ă©tĂ© publiĂ©s sous licence libre par Be et ont donc pu ĂȘtre repris directement par Haiku. Contrairement Ă  la DeskBar, la publication du code du Tracker avait conduit Ă  l’apparition de nombreux forks, chacun amĂ©liorant Ă  sa façon le logiciel. La version utilisĂ©e par Haiku provient principalement du projet OpenTracker, mais a rĂ©intĂ©grĂ© ou rĂ©implĂ©mentĂ© au fil du temps les modifications faites dans d’autres variantes.

Le Tracker est un composant central de l’interface de Haiku et a donc reçu un nombre assez important d’évolutions :

La taille des fichiers est maintenant affichĂ©e Ă  l’aide de la fonction string_for_size qui s’adapte aux conventions de la langue et du pays choisi par l’utilisateur.

Les brouillons de courrier Ă©lectronique disposent maintenant de leur propre type MIME et de l’icĂŽne associĂ©e. Ils s’ouvriront dans un Ă©diteur de mail plutĂŽt que dans une fenĂȘtre de lecture de message.

Pour les fichiers qui disposent d’un attribut « rating » (Ă©valuation), ce dernier est affichĂ© avec des Ă©toiles pleines ou vides selon la note attribuĂ©e. La note va de 0 Ă  10 mais il n’y a que 5 Ă©toiles. Le caractĂšre demi-Ă©toile permet d’afficher la note exacte avec les versions rĂ©centes d’Unicode (depuis 2018 en fait, mais il a fallu attendre la disponibilitĂ© dans une police de caractĂšres).

Une fenĂȘtre du Tracker, montrant la colonne taille et la colonne rating

La gestion des dossiers en lecture seule a Ă©tĂ© amĂ©liorĂ©e. Ils sont affichĂ©s sur fond gris (au lieu d’un fond blanc pour les dossiers modifiables) et tous les menus correspondant Ă  des opĂ©rations non autorisĂ©es sont dĂ©sactivĂ©s (au lieu d’ĂȘtre activĂ©s, mais d’aboutir sur une erreur car le dossier est en lecture seule).

Dans le mĂȘme esprit, le bouton « ouvrir » des boĂźtes de dialogues d’ouverture de fichier est dĂ©sactivĂ© si le fichier sĂ©lectionnĂ© ne peut pas ĂȘtre ouvert (c’était dĂ©jĂ  le cas, mais tous les cas possibles n’étaient pas bien pris en compte).

Un problĂšme d’affichage sur le systĂšme de fichier packagefs a Ă©tĂ© corrigĂ© : les dossiers n’ont pas de taille et affichent donc - au lieu d’une taille fixe de 4 Kio qui n’a aucune signification.

La fenĂȘtre de recherche a reçu quelques Ă©volutions, voir plus bas dans la section dĂ©diĂ©e au Google Summer of Code, qui dĂ©taille le travail rĂ©alisĂ© Ă  ce sujet.

Le menu « templates », utilisĂ© quand on fait un 'clic droit -> Nouveau
' et qui permet de crĂ©er diffĂ©rents types de fichiers et de dossiers Ă  partir de fichiers de rĂ©fĂ©rence, peut maintenant contenir des sous-dossiers, pour les personnes qui utilisent beaucoup cette possibilitĂ©, avec par exemple des modĂšles de documents prĂ©-remplis pour diffĂ©rents usages.

Enfin, un peu de nettoyage interne : les classes NavMenu et SlowContextPopup, qui permettent la navigation dans les sous-dossiers via des menus popup, ont Ă©tĂ© fusionnĂ©es en une seule classe car elles sont toujours utilisĂ©es ensemble. Cela simplifie le code pour l’affichage de ces menus, qui a quelques particularitĂ©s pour permettre une navigation confortable mĂȘme sur un disque dur un peu lent.

TV

L’application TV utilisĂ©e pour recevoir la TNT Ă  l’aide d’un tuner appropriĂ© a Ă©tĂ© dĂ©placĂ©e dans le paquet haiku_extras et n’est donc plus installĂ©e par dĂ©faut. La plupart des gens ne disposant pas d’un tuner compatible sur leur ordinateur, cette application Ă©tait source de confusion et de nombreuses questions sur le forum.

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit développé conjointement par Apple, Igalia et Sony principalement.

En dehors de la mise Ă  jour du moteur vers une version plus rĂ©cente, WebPositive reçoit actuellement peu d’évolutions, les dĂ©veloppeurs Ă©tant malheureusement trop occupĂ©s par ailleurs. On peut toutefois mentionner une correction sur la barre de signets : celle-ci ne s’affichait jamais lorsque la langue du systĂšme Ă©tait autre chose que l’anglais.

Zip-O-Matic

Zip-O-Matic est un outil permettant de crĂ©er une archive zip facilement depuis le Tracker. Il a reçu une amĂ©lioration qui est en fait une correction d’un problĂšme qui existait depuis longtemps : l’archive crĂ©Ă©e est maintenant automatiquement sĂ©lectionnĂ©e dans le navigateur de fichier Ă  la fin du processus, ce qui permet de facilement la retrouver pour la renommer, la dĂ©placer ou l'envoyer Ă  son destinataire.

Haikuports

Haikuports est un projet indĂ©pendant de Haiku, il se charge d’alimenter le dĂ©pĂŽt de paquets. Au dĂ©part il s’agissait principalement d’un projet pour le portage de bibliothĂšque et de programmes venant d’autres systĂšmes (d’oĂč son nom), mais il est Ă©galement utilisĂ© pour la plupart des applications natives dĂ©veloppĂ©es pour Haiku.

Le dĂ©pĂŽt de paquets contient actuellement 4193 paquets, il est mis Ă  jour en continu par une petite Ă©quipe de bĂ©nĂ©voles qui ne sont pas forcĂ©ment tous dĂ©veloppeurs, mais tout de mĂȘme capables de faire les tĂąches de maintenance ainsi que le dĂ©veloppement de quelques patchs simples.

Il est impossible de lister toutes les mises à jour et ajouts, le projet HaikuPorts étant trÚs actif. Donc voici une sélection arbitraire de quelques nouveautés et mises à jour.

Applications natives

  • Mises Ă  jour de Renga (client XMPP), PonpokoDiff (outil de diff), 2pow (clone de 2048), StreamRadio (lecteur de podcasts), NetSurf (navigateur web lĂ©ger)

  • Genio, un IDE pour Haiku avec gestion de la complĂ©tion de code via le protocole LSP (compatible avec les outils dĂ©veloppĂ©s pour VS Code par exemple).
  • Ajout de HaikuUtils, un ensemble d’outils de dĂ©veloppement et de debug divers.
  • WorkspaceNumber, un replicant pour afficher le numĂ©ro du bureau actif dans la DeskBar.
  • KeyCursor, un outil pour contrĂŽler le curseur de souris Ă  l’aide du clavier.
  • BatchRename, un outil pour renommer automatiquement des fichiers par lot.

HaikuUtils

WorkspaceNumber

PonpokoDiff

PecoRename

2pow

BatchRename

Applications portées

  • Un gros travail a Ă©tĂ© fait sur le portage de KDE Frameworks et des applications l’utilisant. De trĂšs nombreuses applications Qt et KDE sont donc disponibles.
  • Du cĂŽtĂ© de GTK, il n’existait pas de version de GTK pour Haiku, le problĂšme a Ă©tĂ© rĂ©solu Ă  l’aide d’une couche de compatibilitĂ© avec Wayland qui n’implĂ©mente pas le protocole Wayland mais rĂ©implĂ©mente l’API de la libwayland. Les applications GTK arrivent petit Ă  petit, mais l’intĂ©gration est pour l’instant beaucoup moins bonne qu’avec Qt, qui dispose lui d’un vrai port utilisant les APIs natives directement. L’apparence des applications est trĂšs visiblement diffĂ©rente, certaines touches du clavier ne fonctionnent pas. C’est donc encore un peu expĂ©rimental.
  • Enfin, pour complĂ©ter les possibilitĂ©s d’outils graphiques, la bibliothĂšque Xlibe implĂ©mente les APIs de la libx11 (mais pas le protocole de communication de X) et permet de porter les applications FLTK par exemple, ainsi que celles utilisant directement la libx11. Il reste encore des problĂšmes avec les applications utilisant Tk (si vous connaissez Tk ou X, les dĂ©veloppeurs de Xlibe aimeraient bien un petit coup de main). En attendant, les applications Tk sont utilisables Ă  travers un portage de undroidwish, mais ça reste peu confortable.

Du cĂŽtĂ© des compilateurs et des langages de programmation : LLVM a Ă©tĂ© mis Ă  jour en version 17. GCC est disponible en version 13 et peut maintenant ĂȘtre utilisĂ© pour compiler du FORTRAN et de l’Objective-C. Les derniĂšres versions de Python sont disponibles, et en plus avec des performances amĂ©liorĂ©es. Node.JS est Ă©galement mis Ă  jour, ou si vous prĂ©fĂ©rez le langage R, vous le trouverez Ă©galement, avec son IDE associĂ© rkward.

Bien sĂ»r, la plupart des bibliothĂšques et outils disponibles sur d’autres systĂšmes sont aussi disponibles : ffmpeg (en version 6), Git, libreoffice, Wireshark


Mentionnons enfin un pilote FUSE pour monter des volumes réseau NFS, qui vient compléter les deux implémentations de NFS présentes dans le noyau (une obsolÚte qui implémente NFS2, et une plus récente implémentant NFS4, mais qui est instable et pas activement maintenue actuellement).

GCompris

DrawTerm

KDE Mah Jong

NetBeans

Frogatto

CudaText

Cantor

Panneaux de préférences

Appearance

Les prĂ©fĂ©rences « Appearance » permettent de configurer l’apparence du systĂšme et des applications : principalement les polices de caractĂšres et les choix de couleurs.

C’est ce dernier qui reçoit une mise Ă  jour en profondeur, avec l’ajout d’un mode automatique. Auparavant, chaque couleur utilisĂ©e par le systĂšme devait ĂȘtre configurĂ©e manuellement, ce qui permet un contrĂŽle trĂšs fin, mais demande de passer un certain temps Ă  faire des ajustements. Le mode automatique permet de configurer seulement 3 couleurs : le fond des fenĂȘtres, les barres de titres, et une couleur d’« accentuation ». Les autres couleurs et nuances sont calculĂ©es automatiquement Ă  partir de cette palette de base.

En particulier, il devient beaucoup plus facile de choisir un fond sombre pour se retrouver avec un systÚme en mode sombre, trÚs à la mode chez certain·e·s utilisateurices de Haiku.

Il est toujours possible d’activer le mode avancĂ© pour affiner les rĂ©glages si nĂ©cessaire (ou si vous aimez les interfaces graphiques bariolĂ©es et multicolores).

Le mode automatique dans l’application Appearance

La mĂȘme capture d’écran avec une configuration « mode sombre »

Keymap (disposition clavier)

L’application Keymap permet de configurer la disposition de touches du clavier. Le point qui a reçu un peu d’attention est la gestion de la configuration des touches modificatrices.

Haiku est un dĂ©rivĂ© de BeOS qui lui-mĂȘme a Ă©tĂ© au dĂ©part inspirĂ© de Mac OS. On conserve de cet hĂ©ritage l’utilisation des touches commande et option au lieu de meta et alt sur les claviers de PC. Mais BeOS et Haiku sont conçus pour ĂȘtre utilisĂ©s avec des claviers de PC. La touche commande qui prend la place de la touche ALT est donc celle utilisĂ©e pour la plupart des raccourcis claviers. Cela se complique si on essaie d’utiliser un clavier fabriquĂ© par Apple (les codes de touches renvoyĂ©s par le clavier pour des touches situĂ©es au mĂȘme endroit ne sont pas les mĂȘmes), ou encore si on a besoin d’une touche AltGr (historiquement utilisĂ©e comme touche option par BeOS, mais aujourd’hui ce rĂŽle est plutĂŽt attribuĂ© Ă  la touche windows apparue un peu plus tard). Une page sur le wiki de dĂ©veloppement de Haiku tente de rĂ©sumer l’historique et la situation actuelle.

La configuration des touches modificatrices est donc un sujet complexe, et il est probable que le comportement sera Ă  nouveau modifiĂ© plus tard. Quoi qu’il en soit, en attendant, l’application Keymap permet toutes les permutations possibles de configuration de ces touches.

Screen (Affichage)

Les prĂ©fĂ©rences d’affichage, en plus de permettre de changer la rĂ©solution d’écran, affichent quelques informations essentielles sur la carte graphique et l’écran en cours d’utilisation. Pour les Ă©crans, ces informations sont gĂ©nĂ©ralement extraites des donnĂ©es EDID, mais il y a une exception : les dalles d’affichage des PC portables n’implĂ©mentent en gĂ©nĂ©ral pas ce protocole. Les informations sont donc rĂ©cupĂ©rĂ©es par d’autres moyens parfois moins bien normalisĂ©s. Par exemple, l’identifiant du fabricant est un code Ă  3 lettres. En principe, les fabricants doivent s’enregistrer auprĂšs d’un organisme qui attribue ces codes, afin d’en garantir l’unicitĂ©.

Cependant, certains fabricants ne l’ont pas fait, et se sont choisi eux-mĂȘmes un code qui semblait inutilisĂ©. La base de donnĂ©es officielle rĂ©serve donc ces codes et en interdit l’utilisation, afin d’éviter des conflits. Il arrivait donc que le fabriquant d’un Ă©cran soit affichĂ© comme Ă©tant « DO NOT USE », ce qui a inquiĂ©tĂ© quelques utilisateurs de Haiku se demandant s’ils risquaient d’endommager leur matĂ©riel.

Ces entrĂ©es de la liste sont maintenant filtrĂ©es et remplacĂ©es par les noms des fabricants de panneaux d’affichages concernĂ©s (lorsqu’on sait de qui il s’agit).

Outils en ligne de commande

Haiku est fourni avec un terminal et un shell bash (par dĂ©faut, d’autres shells peuvent Ă©galement ĂȘtre utilisĂ©s). Les outils dĂ©finis dans la spĂ©cification POSIX sont fournis, ainsi que des complĂ©ments permettant d’utiliser les fonctionnalitĂ©s supplĂ©mentaires de Haiku.

df

La commande df affiche l’espace disque disponible sur chaque volume de stockage actuellement montĂ©.

Les colonnes de l’affichage ont Ă©tĂ© rĂ©organisĂ©es, pour ĂȘtre plus lisibles, et se rapprocher un peu du format spĂ©cifiĂ© par POSIX (mais pas complĂštement lorsqu’on lance la commande sans options particuliĂšres : des informations supplĂ©mentaires sont alors affichĂ©es).

filteredquery

L’outil filteredquery permet d’effectuer une requĂȘte sur les attributs Ă©tendus du systĂšme de fichiers (permettant de requĂȘter le systĂšme de fichiers comme une base de donnĂ©es, plutĂŽt que de naviguer de façon hiĂ©rarchique dans les dossiers), puis de filtrer le rĂ©sultat pour ne conserver que les rĂ©ponses contenues dans un sous-dossier spĂ©cifique. En effet, les requĂȘtes Ă©tant indĂ©pendantes de l’organisation des dossiers, il est nĂ©cessaire de faire ce filtrage par post-traitement des rĂ©sultats (ce qui reste tout de mĂȘme gĂ©nĂ©ralement plus rapide que de faire l’inverse : parcourir tous les fichiers d’un dossier pour trouver ceux correspondant Ă  un critĂšre particulier).

Cet outil n’a pas reçu de nouvelles fonctionnalitĂ©s, mais de nombreuses corrections et nettoyages qui le rendent vĂ©ritablement utilisable.

ping, traceroute, telnet, ftpd

Ces commandes liĂ©es Ă  des opĂ©rations sur le rĂ©seau ont Ă©tĂ© remplacĂ©es par les derniĂšres versions dĂ©veloppĂ©es par FreeBSD, permettant de bĂ©nĂ©ficier d’une version moderne, avec plus de fonctionnalitĂ©s et moins de bugs.

La commande ping6 est supprimĂ©e, car ping peut maintenant utiliser l’IPv6 aussi bien que l’IPv4.

pkgman

L’outil pkgman permet de tĂ©lĂ©charger et d’installer des logiciels et des mises Ă  jour.

Il a peu Ă©voluĂ©, mais on peut tout de mĂȘme noter l’utilisation d’un algorithme de tri « naturel » pour l’affichage des rĂ©sultats dans l’ordre alphabĂ©tique (par exemple, llvm12 sera affichĂ© aprĂšs llvm9).

Une fonction qui n’est toujours pas disponible dans pkgman est le nettoyage des dĂ©pendances non utilisĂ©es. Un script fourni dans le dĂ©pĂŽt Git de Haiku permet de rĂ©aliser manuellement une analyse des paquets installĂ©s sur le systĂšme pour dĂ©tecter ceux qui n’ont pas de dĂ©pendances, il faudra pour l’instant se contenter de cette solution.

strace

L’outil strace permet d’afficher les appels systĂšmes effectuĂ©s par une application, pour comprendre son interfaçage avec le noyau et investiguer certains problĂšmes de performances ou de mauvais comportements.

L’interfaçage avec le noyau pour extraire ces informations Ă©tant assez spĂ©cifique, l’implĂ©mentation de strace est faite Ă  partir de zĂ©ro, et ne partage pas de code avec la commande du mĂȘme nom disponible par exemple sous Linux.

strace est mis Ă  jour rĂ©guliĂšrement et en fonction des besoins des dĂ©veloppeurs de Haiku pour dĂ©coder et afficher de plus en plus d’informations. Par exemple, elle peut maintenant afficher le contenu des iovec (par exemple pour les fonctions readv ou writev), ainsi que les objets manipulĂ©s par wait_for_object et event_queue.

Un exemple de sortie de strace (traçant l’ouverture d’un fichier et le chargement d’une bibliothĂšque partagĂ©e) avant ces changements:

open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us)
map_file("libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us)

et aprĂšs :

open(0x5, "plaintext", O_RDWR|O_NOTRAVERSE|O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us)
map_file("libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us)

whence

La commande whence permettait de trouver dans le PATH un exĂ©cutable Ă  partir de son nom. Elle Ă©tait implĂ©mentĂ©e sous forme d’une fonction bash dans le fichier profile par dĂ©faut. Cependant, cette implĂ©mentation posait problĂšme pour charger le fichier profile avec d’autres shells, elle a donc Ă©tĂ© supprimĂ©e. La commande which peut ĂȘtre utilisĂ©e Ă  la place, puisqu’elle remplit un rĂŽle Ă©quivalent.

Serveurs

Les serveurs sont l’équivalent des daemons pour UNIX ou des services sous Windows : il s’agit d’applications lancĂ©es par le systĂšme pour rendre diffĂ©rents services et coordonner l’ensemble des applications.

app_server

app_server est le serveur graphique de Haiku, Ă©quivalent de X ou de Wayland. Il se distingue par un rendu graphique fait principalement cĂŽtĂ© serveur (pour les applications natives), ce qui permet de l’utiliser de façon fluide Ă  travers une connexion rĂ©seau.

Bien que ce soit le serveur graphique, et qu’il ait reçu plusieurs amĂ©liorations importantes, les diffĂ©rences sont subtiles. Elles sont toutefois importantes pour proposer un systĂšme qui semble rĂ©actif et confortable Ă  utiliser.

Un premier changement est une rĂ©architecture du code qui traite le rafraĂźchissement de l’écran. Ce rafraĂźchissement se fait en gĂ©nĂ©ral en plusieurs Ă©tapes, par exemple, si on dĂ©place une fenĂȘtre :

  • Le contenu de la fenĂȘtre dĂ©placĂ©e peut ĂȘtre directement recopiĂ© de l’ancienne position vers la nouvelle,
  • La zone oĂč se trouvait la fenĂȘtre auparavant doit ĂȘtre re-remplie avec ce qui se trouvait en dessous de la fenĂȘtre dĂ©placĂ©e. Cela peut ĂȘtre plusieurs morceaux de fenĂȘtres d’autres applications, qui vont devoir chacune rĂ©-afficher une partie de cette zone.

Le problĂšme Ă©tant que certaines applications peuvent mettre un peu de temps Ă  rĂ©pondre Ă  cette demande de rĂ©-affichage (par exemple parce qu’elles sont occupĂ©es ailleurs, ou alors parce que la zone Ă  redessiner est relativement complexe).

DiffĂ©rentes stratĂ©gies peuvent ĂȘtre mises en place dans ce cas : laisser Ă  l’écran le contenu obsolĂšte, ou remplir la zone en blanc en attendant que les donnĂ©es deviennent disponibles, par exemple. Ou encore, tout simplement ne rien mettre Ă  jour du tout tant que tout l’écran n’est pas prĂȘt Ă  ĂȘtre affichĂ©. Il faut faire un compromis entre la rĂ©activitĂ© (dĂ©placer la fenĂȘtre tout de suite), la fluiditĂ© (Ă©viter les clignotements de zones blanches) et la prĂ©cision (affichage d’information cohĂ©rente et Ă  jour).

Plusieurs modifications ont permis d’obtenir un meilleur compromis.

Dans un autre domaine, la police de caractĂšres par dĂ©faut « Noto Sans Display » a Ă©tĂ© remplacĂ©e par « Noto Sans », ce qui donne un affichage du texte lĂ©gĂšrement diffĂ©rent. La police « display » avait Ă©tĂ© choisie suite Ă  une mauvaise comprĂ©hension de la signification de ce mot en typographie : il signifie que c’est une police de caractĂšres Ă  utiliser pour des gros titres et autres textes courts. Il ne signifie pas que c’est une police Ă  utiliser sur un Ă©cran d’ordinateur. De toutes façons la police Noto Display n’est plus maintenue par Google et a disparu des derniĂšres versions du jeu de polices Noto.

Toujours dans le domaine des polices de caractĂšres, app_server sait maintenant charger les fichiers « variable fonts ». Ces fichiers contiennent plusieurs polices de caractĂšres dĂ©finies Ă  partir de glyphes de base, et d’algorithmes de transformation et de dĂ©formation (pour rendre une police plus ou moins grasse, plus ou moins italique
). Pour l’instant, app_server sait charger les valeurs de ces paramĂštres qui sont prĂ©configurĂ©es dans le fichier. Cela permet de rĂ©duire la place utilisĂ©e par les polices de caractĂšres sur le media d’installation de Haiku (c’est l’un des plus gros consommateurs d’espace disque, qui nous empĂȘche de faire tenir une version complĂšte de Haiku sur un CD de dĂ©monstration par exemple).

Plus tard, il sera Ă©galement possible de configurer plus finement ces paramĂštres pour gĂ©nĂ©rer des variantes intermĂ©diaires des polices de caractĂšres, ainsi que d’exploiter certaines polices qui offrent des paramĂštres configurables supplĂ©mentaires.

input_server

L’input_server se charge de lire les donnĂ©es venant des pĂ©riphĂ©riques d’entrĂ©e (clavier et souris) et de les convertir en Ă©vĂšnements distribuĂ©s aux applications. Il est extensible par des add-ons qui peuvent gĂ©nĂ©rer ou filtrer des Ă©vĂšnements, ce qui peut ĂȘtre utilisĂ© pour de l’accessibilitĂ© (Ă©muler une souris Ă  partir de touches du clavier), de l’automatisation (envoi de commandes prĂ©-enregistrĂ©es), du confort d’utilisation (bloquer le touchpad d’un ordinateur portable lorsque le clavier est en cours d’utilisation) et bien d’autres choses.

L’input_server a reçu des corrections de problĂšmes sur la gestion des rĂ©glages de souris, permettant en particulier d’utiliser des rĂ©glages diffĂ©rents pour plusieurs pĂ©riphĂ©riques (souris, touchpad), et que ceux-ci soient bien enregistrĂ©s.

registrar

Le serveur registrar suit les applications en cours de fonctionnement, et leur permet de communiquer entre elles au travers de l’envoi de messages. Il assure Ă©galement le suivi de la base de donnĂ©es des types MIME et des associations de types de fichiers avec les applications correspondantes.

L’implĂ©mentation de BMessageRunner, qui permet d’envoyer des messages pĂ©riodiques (par exemple pour faire clignoter le curseur des zones de texte Ă  la bonne vitesse), autorise maintenant des intervalles de rĂ©pĂ©tition en dessous de 50 millisecondes. Cela permet d’utiliser ce systĂšme pour des animations fluides de l’interface graphique, par exemple.

D’autre part, la liste des applications et documents rĂ©cemment lancĂ©s est maintenant limitĂ©e Ă  100 entrĂ©es. Cela Ă©vite un fichier qui grossit indĂ©finiment et finit par contenir surtout des vieilles informations sans intĂ©rĂȘt.

Kits

Le systĂšme Haiku fournit les mĂȘmes APIs que BeOS. Elles couvrent les usages basiques d’une application, et sont dĂ©coupĂ©es (dans la documentation de BeOS et de Haiku, au moins) en « kits » qui prennent chacun en charge une partie spĂ©cifique (interface graphique, multimĂ©dia, jeux vidĂ©os, accĂšs au matĂ©riel, etc).

Interface

L’interface kit est la partie de la bibliothùque standard qui se charge des interfaces graphiques.

 BColumnListView

BColumnListView est un ajout de Haiku par rapport Ă  BeOS. Il s’agit d’un Ă©lĂ©ment d’interface permettant de prĂ©senter une liste avec plusieurs colonnes, de trier les lignes selon le contenu de ces colonnes, et aussi d’avoir des items hiĂ©rarchisĂ©s avec la possibilitĂ© de plier et dĂ©plier une partie de l’arborescence.

Cette classe remplace avantageusement BListView et surtout BColumnListView, les classes historiques de BeOS, qui sont beaucoup plus limitées.

Un certain nombre de type de colonnes prĂ©dĂ©finis sont Ă©galement disponibles, ce qui facilite la construction d’interfaces prĂ©sentant les donnĂ©es de diffĂ©rentes applications avec le mĂȘme formatage.

La classe BColumnListView elle-mĂȘme n’a pas changĂ©. Par contre, les colonnes de type « taille » (pour afficher une taille en Kio, Mio, Gio
) et « date » utilisent la langue choisie dans les prĂ©fĂ©rences systĂšme au lieu d’un format anglais par dĂ©faut.

BTextView

BTextView est une classe permettant d’afficher une zone de texte Ă©ditable. Elle implĂ©mente les fonctionnalitĂ©s de base (curseur, sĂ©lection, retour Ă  la ligne automatique) ainsi que quelques possibilitĂ©s de mise en forme (couleurs, polices de caractĂšres).

BTextView peut Ă©galement ĂȘtre utilisĂ©e pour des zones de textes non Ă©ditables, souvent plus courtes. Cela permet de rĂ©utiliser une partie des algorithmes de mise en page et de formatage du texte dans diffĂ©rents contextes. Dans le cadre de l’utilisation du « layout system », une vue doit pouvoir indiquer sa taille minimale, maximale et optimale. Le « layout system » va ensuite calculer la meilleure disposition de fenĂȘtre possible pour satisfaire ces contraintes.

Le cas des zones de texte est particulier, car la hauteur optimale dĂ©pend du nombre de lignes de texte, qui lui-mĂȘme peut ĂȘtre plus ou moins grand si la largeur de la vue oblige Ă  ajouter des retours Ă  la ligne. Le « layout kit » prend en compte ce cas particulier, mais les algorithmes ne sont pas encore tout Ă  fait au point et peuvent conduire Ă  des rĂ©sultats inattendus dans certains cas. Un de ces cas particuliers sur les zones de texte non Ă©ditables a Ă©tĂ© corrigĂ©.

BMenu

La classe BMenu permet d’afficher un menu. Elle est utilisĂ©e de plusieurs façons, puisqu’on trouve des menus dans des barres de menu, dans des contrĂŽles de type « popup », ou encore en faisant un clic droit sur certains Ă©lĂ©ments de l’interface.

Les menus sont Ă©galement particuliers parce qu’ils peuvent d’étendre en dehors de la fenĂȘtre dont ils sont originaires. Ils sont donc implĂ©mentĂ©s sous forme de fenĂȘtres indĂ©pendantes. Mais cela pose un autre problĂšme : dans Haiku, chaque fenĂȘtre exĂ©cute son propre thread et sa propre boucle d’évĂšnements. Si on navigue dans un grand nombre de menus et de sous-menus, cela peut causer quelques problĂšmes de synchronisation et de performances.

Le code contient Ă©galement un grand nombre de cas particuliers pour, par exemple, aligner les raccourcis claviers et les flĂšches indiquant la prĂ©sence de sous-menus ente les diffĂ©rents items d’un menu, ou encore dĂ©tecter si un dĂ©placement de souris a pour but de sĂ©lectionner un autre menu (en dessous ou au-dessus de celui actif), ou bien plutĂŽt de naviguer vers un sous-menu.

Les nouveautés suivantes sont apparues cette année:

  • Correction de problĂšmes de race condition lors de l’ajout d’items dans un menu pendant qu’il est affichĂ© Ă  l’écran. Ce problĂšme se manifestait par exemple dans les menus affichant la liste des rĂ©seaux Wifi, qui sont mis Ă  jour en temps rĂ©el.
  • Finalisation de l’implĂ©mentation de la navigation au clavier (avec les flĂšches directionnelles) dans les menus.
  • Affichage des symboles graphiques UNICODE pour « backspace » (⌫) et « delete » (〈) si ces touches sont utilisĂ©es comme raccourcis clavier pour un item de menu.
  • Utilisation d’un algorithme de tri stable pour la fonction SortItems. Ce type d’algorithme prĂ©serve l’ordre relatif des items qui sont Ă©gaux d’aprĂšs la fonction de comparaison. Ce n’est pas le cas de certains algorithmes de tri classiques, notamment le quicksort. La consĂ©quence Ă©tait que trier un menu dĂ©jĂ  triĂ© pouvait changer l'ordre des items. C’était visible encore une fois sur le menu listant les rĂ©seaux Wifi, qui est triĂ© par puissance du signal reçu.

 BSpinner

BSpinner est un contrĂŽle permettant de choisir une valeur numĂ©rique, soit Ă  l’aide de boutons +/- pour modifier la valeur par incrĂ©ments, soit en entrant directement la valeur dans une zone de texte.

Il s’agit d’une extension de Haiku par rapport Ă  BeOS qui ne proposait pas cette fonctionnalitĂ©.

Cette classe est encore en cours de développement. Elle a reçu des améliorations pour désactiver correctement les boutons +/- lorsque la valeur atteint le minimum ou le maximum autorisé, et aussi une correction sur le message de notification envoyé lors des changements de valeurs du spinner, qui ne contenaient pas la bonne valeur.

rgb_color

La structure rgb_color permet de reprĂ©senter une couleur par la valeur de ses composantes rouge, vert, bleu (comme son nom l’indique) et alpha (comme son nom ne l’indique pas). Elle fournit Ă©galement un certain nombre de fonctions pour mĂ©langer des couleurs, les Ă©claircir ou les assombrir.

La mĂ©thode Brightness() dans la classe rgb_color implĂ©mentante maintenant l’algorithme perceptual brightness documentĂ© par Darel Rex Finley, qui donne des meilleurs rĂ©sultats que l’algorithme utilisĂ© prĂ©cĂ©demment (qui Ă©tait celui de la luminositĂ© dans l’espace de couleurs Y'IQ. La fonction perceptual_brightness devenue redondante est supprimĂ©e.

Cette mĂ©thode permet en particulier de dĂ©terminer si une couleur est « sombre » ou « claire », et ainsi de dĂ©cider si du texte affichĂ© par-dessus doit ĂȘtre blanc ou noir (comme dĂ©montrĂ© ici par exemple).

Locale

Le locale kit se charge de tous les aspects liés à la localisation : traductions des applications, formatage des messages en utilisant les rÚgles de pluralisation de chaque langue, formatage de dates, de nombres avec et sans unités, de pourcentages, nom des fuseaux horaires


Il utilise ICU pour implĂ©menter la plupart de ces fonctionnalitĂ©s, mais fournit une surcouche avec une API s’intĂ©grant mieux avec les autres kits.

La principale Ă©volution cette annĂ©e est l’implĂ©mentation de BNumberFormat, qui permet de formater des nombres. Elle permet de choisir une prĂ©cision (nombre de dĂ©cimales - pour les langues qui utilisent un systĂšme dĂ©cimal), d’afficher ou non des sĂ©parateurs de groupes (de milliers en français, mais par exemple en Inde la sĂ©paration se fait traditionnellement par multiples de 10 000).

Media

Le media kit se charge de tous les aspects multimedia.

Il se compose de deux parties. D’une part, un systĂšme de gestion de flux mĂ©dia temps rĂ©el, permettant de transfĂ©rer des donnĂ©es multimĂ©dia (son ou flux vidĂ©o par exemple) entre diffĂ©rentes applications qui vont les manipuler, le tout avec un certain contrĂŽle du temps de traitement ajoutĂ© par chaque opĂ©ration, pour tenter de minimiser la latence tout en Ă©vitant les vidages de tampons qui produiraient une interruption dans le flux. D’autre part, des classes permettant d’encoder et de dĂ©coder des fichiers mĂ©dia et d’en extraire des flux de donnĂ©es (encodĂ©es ou dĂ©codĂ©es).

C’est surtout cette deuxiĂšme partie qui a reçu quelques Ă©volutions. La version de ffmpeg utilisĂ©e pour le dĂ©codage de presque tous les formats audio et video est maintenant la derniĂšre version ffmpeg 6. Quelques autres problĂšmes (erreurs d’arrondis, gestion des tampons partiels en fin de fichier) ont Ă©galement Ă©tĂ© corrigĂ©s, ce qui permet de faire fonctionner Ă  nouveau le jeu BePac Deluxe qui est extrĂȘmement intolĂ©rant au moindre Ă©cart de comportement par rapport Ă  l’implĂ©mentation du Media Kit dans BeOS.

Support

Le support kit contient un ensemble de classes basiques mais indispensables : gestion des chaßnes de caractÚres, des tampons en mémoire, etc. Il fournit les briques de bases utilisées par les autres kits.

BDataIO

BDataIO est une classe abstraite avec des fonctions de lecture et d’écriture. Plusieurs autres classes sont des instances de BDataIO, par exemple BFile (reprĂ©sentant un fichier), mais aussi BMemoryIO (permettant d’accĂ©der Ă  une zone mĂ©moire).

Plusieurs autres classes acceptent BDataIO (ou sa sous-classe BPositionIO, qui ajoute la possibilitĂ© de se dĂ©placer Ă  une position donnĂ©e dans le flux) comme entrĂ©e ou comme sortie. Il est donc facilement possible de rĂ©aliser les mĂȘmes opĂ©rations sur un fichier, une zone de donnĂ©es en mĂ©moire, un socket rĂ©seau, ou tout autre objet susceptible de fournir une interface similaire.

BDataIO elle-mĂȘme n’a pas Ă©voluĂ©, mais deux de ses implĂ©mentations, BBufferedDataIO et BAdapterIO, ont Ă©tĂ© amĂ©liorĂ©es. Ces deux classes permettent de construire un objet BDataIO Ă  partir d’un autre, en ajoutant un cache en mĂ©moire pour accĂ©lĂ©rer les opĂ©rations ou encore pour rendre compatible avec BPositionIO un objet qui ne l’est pas.

Ces classes sont en particulier utilisĂ©es par l’application StreamRadio, qui implĂ©mente la lecture de podcasts en connectant directement le rĂ©sultat d’une requĂȘte HTTP (effectuĂ©e grace au network kit) dans un dĂ©codeur audio (via la classe BMediaFile du media kit). La mise en tampon permet de revenir en arriĂšre dans la lecture d’un Ă©pisode, de tĂ©lĂ©charger en avance les donnĂ©es qui vont ĂȘtre lues, et d’éviter de conserver inutilement en mĂ©moire les donnĂ©es qui sont dĂ©jĂ  lues par l’application.

BibliothĂšques C

Les « kits » mentionnĂ©s ci-dessus sont l’API en C++ utilisĂ©e par les applications Haiku.

Il existe aussi des APIs en C, en grande partie implémentant la bibliothÚque C standard et les fonctions décrites dans la spécification POSIX.

Libroot

Libroot implĂ©mente la bibliothĂšque standard C. Elle regroupe entre autres la libc, la libm, et la libpthread, qui sont parfois implĂ©mentĂ©es comme 3 bibliothĂšques diffĂ©rentes pour d’autres systĂšmes. Les Ă©volutions consistent Ă  complĂ©ter l’implĂ©mentation de la spĂ©cification POSIX, et Ă  suivre les Ă©volutions de cette derniĂšre ainsi que des nouvelles versions du langage C. On trouve Ă©galement des corrections de bugs dĂ©couverts en essayant de faire fonctionner de plus en plus d’applications sur Haiku, ce qui permet de mettre en Ă©vidence des diffĂ©rences de comportement avec d’autres systĂšmes.

  • Ajout de getentropy pour initialiser les gĂ©nĂ©rateurs de nombres alĂ©atoires
  • Correction de problĂšmes de locks au niveau de l’allocateur mĂ©moire lors d’un fork
  • Plusieurs corrections sur l’implĂ©mentation de locale_t, remplacement de code Ă©crit pour Haiku ou provenant de FreeBSD par une implĂ©mentation simplifiĂ©e mais suffisante, provenant de la bibliothĂšque C musl.
  • Ajout de static_assert en C11
  • Correction d’un crash lors de l’utilisation de certaines fonctions XSI
  • Ajout de stpncpy
  • La fonction open utilisĂ©e sur un lien symbolique pointant vers un fichier non existant peut maintenant crĂ©er le fichier cible.
  • Il est possible d’utiliser mmap sur un fichier plus grand que la mĂ©moire disponible sans avoir besoin de spĂ©cifier le flag MAP_NORESERVE
  • Utiliser rename pour renommer un fichier vers lui-mĂȘme ne retourne plus d’erreur (conformĂ©ment Ă  la spĂ©cification POSIX).
  • Ajout de pthread_sigqueue

Libnetwork

La libnetwork implĂ©mente les APIs nĂ©cessaire pour se connecter au rĂ©seau (sockets, rĂ©solution DNS
). Elle est sĂ©parĂ©e de la bibliothĂšque C pour des raisons historiques : l’implĂ©mentation de TCP/IP pour BeOS avait Ă©tĂ© rĂ©alisĂ©e entiĂšrement en espace utilisateur (le noyau n’offrant qu’une interface pour envoyer et recevoir des paquets ethernet sur la carte rĂ©seau). Cela a posĂ© des problĂšmes de compatibilitĂ© avec d’autres systĂšmes, et des problĂšmes de performance. Haiku est donc compatible avec la version "BONE" de BeOS, qui implĂ©mente la pile rĂ©seau dans le noyau.

  • Mise Ă  jour du rĂ©solveur DNS Ă  partir du code de NetBSD 9.3. PrĂ©cĂ©dement le code utilisĂ© Ă©tait celui du projet netresolv de NetBSD, mais ce projet n’a pas connu de nouvelles publications et le code est Ă  nouveau maintenu directement dans NetBSD sans publication sĂ©parĂ©e.
  • Correction d’un crash lors de l’utilisation de multicast IPv4

LibBSD

La libbsd implĂ©mente plusieurs extensions fournies par la libc de certains systĂšmes BSD. Elle est sĂ©parĂ©e de la bibliothĂšque C principale pour limiter les problĂšmes de compatibilitĂ©: certaines applications prĂ©fĂšrent fournir leur propre version de ces fonctions, ou d’autres fonctions avec le mĂȘme nom mais un comportement diffĂ©rent. Elles peuvent alors s’isoler en n’utilisant pas la libbsd pour Ă©viter toute interfĂ©rence.

LibGNU

De façon similaire à la libbsd, la libgnu fournit des fonctions qui sont disponibles dans la glibc (la bibliothùque C du projet GNU) mais ne font pas partie d’un standard (C ou POSIX).

  • Ajout de sched_getcpu pour savoir sur quel cƓur de CPU le thread appelant est en train de s’exĂ©cuter.
  • Ajout de pthread_timedjoin_np, pour attendre la fin de l’exĂ©cution d’un thread (comme pthread_join mais avec un timeout.

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌
❌