DragonFly BSD 4.4

Le 7 décembre dernier, Justin Sherill a officiellement annoncé la disponibilité de DragonFly BSD 4.4 en version finale (et non le 4 décembre, comme annoncé ailleurs…). Comme cela est le cas depuis quelques versions, la pile DRM a subi de profonds changements améliorant grandement la prise en charge des GPU Intel et AMD. La pile réseau, elle, a été revue afin d’en améliorer (encore) les performances. Autre point majeur : une revue en profondeur de la prise en charge des locales et collation en fonction de celles-ci. De plus amples détails se trouvent dans la suite de la dépêche.

Sommaire

• Noyau
  • En bref
  • Pilotes graphiques
  • Réseau
  • Systèmes de fichiers et stockage
    • Gestion des périphériques
    • HAMMER
    • HAMMER2
• Espace utilisateur
  • Chamboulement complet du système de locales
  • Collation
  • Bibliothèque TRE
  • OpenLibm
  • Dports
  • Éditeur de liens Gold
  • Version des symboles
  • Évolutions des logiciels intégrés dans le système de base
• Divers
  • Améliorations du bootloader
  • Status de Clang
  • Technologies de gestion d'énergie

Noyau

En bref

• Amélioration de l'économie d'énergie CPU ;
• Ajout d'un nouveau pilote corepower(4), contribution de Imre Vadász ;
• Réduction de la contention lors de l'allocation de fichiers ;
• Réduction de la contention kqueue ;
• ACPICA mis à jour vers 20151124 ;
• Suppression de l'ordonnanceur disque dsched, connu pour comporter de nombreux bugs depuis des années qui n'ont jamais été corrigés, et qui avait des problèmes avec les SSDs ;
• Changement des algorithmes de gestion de situations mémoires basses et du tueur OOM.
• La suppression de code prévu pour gérer l'architecture i386 (32-bit) est presque finie grâce à un sacré nombre de commits de Sascha Wildner

Pilotes graphiques

L'affichage DRM de la console est maintenant activé par défaut. Les terminaux virtuels ne devraient plus afficher d'écran noir après l'activation du mode graphique sous X.Org.
Le système traditionnel de terminaux virtuels utilisé depuis les années 1990 s'attendait à parler à un adaptateur d'affichage compatible VGA, mais depuis la mise en place de la gestion des modes d'affichage dans le noyau (KMS), les adaptateurs d'affichage sont laissés dans leur mode de fonctionnement natif et ne peuvent plus gérer le mode texte 80x25 caractères traditionnel une fois initialisés en mode graphique.
Passer d'un environnement X11 à un terminal texte avec ctrl-alt-f1 par exemple affichait juste ainsi un écran noir.
Le nouveau système de console permet d'afficher à nouveau des caractères texte tout en restant en mode graphique et sans changer la résolution de l'écran.

Le pilote drm/i915 était auparavant basé sur Linux 3.14 et a été mis à jour vers Linux 3.18. Il inclut également quelques correctifs de bugs basés sur Linux 3.19.

Les changements principaux sont :

• Une grande amélioration du support pour les GPUs Broadwell :
  • L'accéleration est maintenant complètement opérationelle,
  • Le cache eDRAM L4 géant est maintenant activé quand il est présent (certaines puces Broadwell ont un cache L4 de 128MB),
  • Les commandes GPU peuvent maintenant être soumises via un nouveau mécanisme execlist ;
• Les GPUs Valleyview / Baytrail (SOCs Atom 22nm) sont maintenant pris en charge ;
• Ajout de la prise en charge des GPUs Cherryview (SOCs Atom 14nm, non testé) ;
• Travail préparatoire pour pouvoir gérer les GPUs de la famille Skylake ;
• Amélioration de la gestion de l'énergie en fonctionnement ;
• La technologie Panel Self-Refresh (PSR) est maintenant activée par défaut sur les familles de GPU Haswell et Broadwell, ce qui contribue à diminuer encore plus la consommation d'énergie.

Comme d'habitude, ces changements majeurs s'accompagnent de corrections de bugs et d'améliorations de performances diverses pour la plupart des générations de GPU.

Le pilote drm/radeon était quant à lui auparavant basé sur Linux 3.11 et a été mis à niveau vers Linux 3.18 par Rimvydas Jasinskas.
Les capteurs de température sont maintenant gérés.

Réseau

La couche réseau a, une fois de plus, été l’œuvre d'un travail en profondeur par Sepherosa Ziehau. On peut noter notamment l'implémentation en mode asynchrone de pru_attach pour TCP et UDP et pru_connect pour UDP, ce qui permet de soutenir des charges de travail encore plus élevées.

Un pilote iwm(4) a été ajouté pour la gestion des cartes Wifi 802.11ac Intel AC 3160, AC 7260 et AC 7265.
Le pilote re(4) a été modifié pour prendre en charge les puces réseau Realtek 8168H.

Parmi les nombreuses améliorations dans la gestion du réseau apportées par DragonFly 4.4, on peut noter également:

• Une fenêtre TCP plus large par défaut, ce qui permet d'obtenir de meilleurs taux de transfert avec des connections à latence élevées
• Les valeurs nmbcluster sont maintenant ajustables à la volée, ce qui est utile pour la gestion de trafic réseau ayant besoin de performances extrêmes
• Certains éléments de la pile IPv6 ont été synchronisés avec FreeBSD; rtadvd(8) et rtadvctl(8) ont été importés depuis FreeBSD 10.
• Les performances de l'appel système socket(2) ont été améliorées pour les connexions TCP et UDP
• L'appel système accept(4) a été ajouté
• La gestion des flags SOCK_CLOEXEC and SOCK_NONBLOCK pour les appels système socket(2) et accept4(2) a été ajouté
• Import d'une version améliorée de ipfw depuis FreeBSD, appelée ipfw3 dans DragonFly.

Systèmes de fichiers et stockage

Gestion des périphériques

Tomohiro Kusumi a apporté de nombreuses corrections de bugs au pilote de disques virtuels dm(4).
Il a également ajouté des cibles dm-flakey et dm-delay afin de simuler des erreurs disques et des latences élevées. Ces nouvelles fonctionnalités seront très utile pour améliorer la tolérance aux pannes et la robustesse des systèmes de fichier HAMMER et HAMMER2.

HAMMER

Tout comme pour la précédente version de DragonFly, Tomohiro Kusumi a procédé à un grand nettoyage du code de HAMMER. En fait, le nombre de ses commits sur ce système de fichier en font même le contributeur principal à DragonFly en terme de nombre de commits pour cette version (plus de 300)!
Son travail s'étend de simples corrections de commentaires dans les sources ou de page de manuel à de corrections plus importantes, du refactoring ou des améliorations de performances voir de la suppression de code obsolète.
On peut noter notamment l'ajout de fonctions relatives aux statistiques sur les zones.

HAMMER2

Hammer2 gère maintenant les points de montage racine et la déduplication à la volée. Des systèmes de fichier Hammer2 peuvent être créés pour tester sur une machine unique.
La récupération de l'espace disque libéré n'est toujours pas automatique et le système de fichier peut se retrouver dans un état non récupérable si l'espace libre vient à manquer.
Comme toutes les opérations sont du type copy-on-write, des mécanismes additionnels sont nécessaires pour rectifier une situation où il n'y a plus d'espace libre.

L'option WANT_HAMMER2 a besoin d'être ajoutée dans /etc/make.conf et le système d'exploitation recompilé afin que le code Hammer2 soit activé.

Hammer2 est toujours expérimental et il est recommandé de ne pas l'utiliser sauf avec des données qui peuvent être perdues sans dommage. Le format de stockage physique des données va continuer à changer de manière incompatible.

Le travail a généralement progressé, avec le frontend essentiellement stable et passant la plupart des stress tests pour systèmes de fichier.
Une solution pour le problème des liens durs (concernant le renommage de répertoires faisant partie du chemin pour arriver à un lien dur) a été mise en place. La cible physique du lien dur était précédemment stockée dans le répertoire parent le plus commun de tous les liens durs. Maintenant, la cible du lien dur est placée encore plus haut dans l'arborescence des répertoires, dans le répertoire le plus commun ayant le chflag 'xlink' activé. Les renommages à travers les points xlink ne sont pas autorisés.

Le travail continue sur le backend, qui est l'endroit où toute la sophistication va se trouver. Le backend est maintenant threadé, avec un ou plusieurs threads par disque physique. Le frontend réplique et dispatche les requêtes, collecte les résultats et réalise les opérations de cluster comme la validation de quorum. Il est capable de détacher et annuler le reste d'une requête une fois que suffisamment de progrès a été accompli.
L'idée est que si un disque physique est bloqué, le problème ne se propage pas au frontend et le bloque à son tour. Ce travail est préliminaire mais le design a l'air solide jusqu'à présent.

Les fonctionnalités de clustering ne sont pas prêtes à être testées du tout pour l'instant.

Espace utilisateur

Chamboulement complet du système de locales

Les données pour toutes les catégories de locales (LC_CTYPE, LC_COLLATE, LC_TIME, LC_NUMERIC, LC_MONETARY, LC_MESSAGES) proviennent maintenant d'une seule source, le Unicode CLDR Project .

Plusieurs locales avec trois composants ont été introduites, comme zh_Hans_CN, zh_Hant_TW ou sr_cyrl_RS et certaines variantes utilisant des codages anciens comme ISO8859-1 éliminées.

Collation

DragonFly est le premier système BSD à prendre en charge proprement la collation pour les locales. Ceci signifie que les données sont triées en fonction des règles de la langue et du territoire sélectionnées.
Avant la version 4.4, les données étaient triées en fonction du standard POSIX, suivant l'ordre du jeu de caractères.

Les définitions de collation proviennent du projet CLDR (Unicode Common Locale Data Repository), version 27.01. Le format de collation, l'outil de génération et sa prise en charge dans la bibliothèque C sont issus du projet Illumos.

Comme cela est un but à long terme du projet FreeBSD, le code de collation de DragonFly a déjà été importé dans FreeBSD CURRENT et sera disponible pour la version 11.0.
Il y a eu une collaboration significative entre FreeBSD et DragonFly en ce qui concerne la découverte et la correction de bugs et des patches ont été remontés vers Illumos. Au final, nous avons une solution de gestion de locale pour trois plate-formes, ce qui fait une histoire FOSS positive (voir notamment le billet de Baptiste Daroussin sur son blog).

Bibliothèque TRE

La bibliothèque regex a été remplacée par la bibliothèque TRE, bien plus puissante et capable de gérer des chaines de caractères encodées en multi-octets.
DragonFly est le premier système d'exploitation *BSD à utiliser TRE après Mac OS X.

OpenLibm

La bibliothèque libm a été remplacée par OpenLibm, essentiellement issue du projet OpenBSD. Elle est développée par une équipe dédiée et est presque complète.
Quelques fonctions manquantes pour gérer complètement la norme C++11 ont été importées depuis NetBSD.
L'ancienne libm était un assemblage de code de différentes origines qu'il était difficile de maintenir.

Dports

Grâce au travail conséquent de John Marino et d'autres contributeurs, plus de 22'800 paquets sont disponibles via les DPorts. GitHub a notamment beaucoup été utilisé récemment par des utilisateurs de DragonFly afin de soumettre des correctifs permettant d'importer des ports qui ne compilaient autrefois pas (ou plus) sur DragonFly.

Éditeur de liens Gold

DragonFly utilise maintenant l'éditeur de liens Gold par défaut. L'ancien éditeur de liens "ld.bfd" est toujours disponible et peut être à nouveau utilisé moyennant quelques changements dans le fichier make.conf.

Version des symboles

De nombreuses bibliothèques avaient bénéficié du Symbol Versioning dans les versions précédentes de DragonFly. C'est maintenant au tour de la libc de bénéficier de cette technologie.
D'un point de vue pratique, ceci devrait permettre à des programmes binaires créés sous DragonFly 4.4 de continuer à pouvoir être executés pendant des années sous de nouvelles versions de DragonFly.

Évolutions des logiciels intégrés dans le système de base

• Ajout de tcpdrop(8)
• Ajout de libexecinfo (depuis FreeBSD)
• nvi a été mis à jour en version 2.1.3
• iconv a été synchronisé depuis FreeBSD
• OpenSSL a été mis à jour en version 1.0.1q
• xz a été mis à jour vers la version 5.2.2. Cette version apporte notamment la prise en charge du multithreading pour la phase de compression.
• libedit a été mis à jour vers la version 2015-03-25
• grep a été mis à jour vers la version 2.22
• tcsh a été mis à jour vers la version 6.19.00
• libdialog a été mis à jour vers la version v1.2-20150920
• (tn)ftp a été mis à jour vers la version "10 OCT 2015"
• binutils a été mis à jour vers la version 2.25.1
• gcc a été mis à jour vers la version 5.2.1
• localedef a été ajouté, en provenance d'Illumos, afin de remplacer mklocale et colldef qui ont logiquement été retiré.
• patch(1): suppression des fonctionnalités d'auto-checkout RCS et SCCS. Message de commit.
• hostapd a été retiré de base. Une version récente est évidemment disponible via les dports.

Divers

Améliorations du bootloader

L'évolution générale de la taille des modules noyau ces dernières années a fini par causer des problèmes de manque de mémoire pour le bootloader; les symptômes étaient souvent une impossibilité d'utiliser une image mémoire initrd pour démarrer sur un disque chiffré ou en mode single user.

Afin de corriger ce problème une bonne fois pour toutes, le bootloader utilise maintenant une zone mémoire de 1Mo située en mémoire haute et non plus dans une zone mémoire gérée par le BIOS.

Status de Clang

Le dport Clang fonctionne presque parfaitement sous DragonFly mais n'est pas encore capable de construire le bootloader. Clang n'est donc pas pour le moment supporté de manière officielle.
John Marino a pour intention de faire de Clang l'un des deux compilateurs intégrés dans DragonFly une fois que les problèmes empêchant la création du bootloader seront réglés.

DragonFly est toujours fourni avec deux compilateurs, qui sont actuellement gcc-4.7.x et gcc-5.2.1, gcc-5.2.1 étant le compilateur utilisé par défaut.

Technologies de gestion d'énergie

DragonFly possède maintenant de nombreuses technologies de gestion d'énergie. Sepherosa Ziehau en a fait un résumé dans ce mail