DragonFly BSD 4.0

Après 3 RC, DragonFly BSD 4.0 a été annoncée par Justin Sherril. Elle est disponible au téléchargement en version finale depuis le 26 novembre 2014. Cette version comprend notamment la prise en charge des GPU de la famille Haswell ainsi que le support d'OpenGL et un nouveau générateur de nombres pseudo-aléatoires pour /dev/random. Plus d'informations se trouvent dans la suite de la dépêche.

Sommaire

• Noyau
  • Ajout de /dev/upmap et /dev/kpmap
  • Ajout de reapctl(2) procctl(2)
  • Augmentation de la limite du nombre de CPU
  • Pilotes graphiques
  • Réseau
  • Packet Filter (pf)
  • Pilotes RAID
  • Crypto
• Espace utilisateur
  • Mises à jour diverses
  • Ajout de rcreload
  • Import de service(8)
• Divers
  • Abandon de i386
  • GNOME 3.x et Cinnamon débarquent
  • Rust porté sous DragonFly BSD
  • FreePascal est désormais disponible
  • DragonFly se prépare a clang
• Notes de mise à jour

DragonFly BSD 4.1 (version de développement) tournant sur un portable Thinkpad T420 avec environnement X et Xfce, via le pilote i915. Hammer est utilisé en tant que système de fichier principal.

Noyau

Ajout de /dev/upmap et /dev/kpmap

Les fichiers spéciaux de périphériques /dev/upmap et /dev/kpmap ont été ajoutés. Ces deux périphériques projetables en mémoire avec mmap(2) permettent d'accéder à un espace mémoire partagé par processus ou global au noyau. L'objectif ici est de permettre l'obtention d'information de manière plus efficace qu'en passant par un appel système plus coûteux. Le fonctionnement est différent de VDSO sous Linux mais le but identique : éviter des appels systèmes. Alors que /dev/upmap est accessible en écriture et permet un mappage par processus utilisateur, /dev/kpmap est en lecture seule et peut être utilisé pour le mappage par CPU au niveau du noyau.

Le but initial était de répondre au même besoin que la fonctionnalité INHERIT_ZERO introduite par OpenBSD pour régler les problèmes liés aux générateurs de nombres pseudo-aléatoires en espace utilisateur. En effet, la bibliothèque de génération de nombres aléatoires conserve une amorce d'entropie dans un tableau, qui est utilisée comme état du générateur. Mais quand le processus forke, il faut réinitialiser cet état en obtenant de l'entropie auprès du noyau pour éviter que les nombres générés par le processus fils soient les mêmes que ceux générés par le processus parent, sinon cela pourrait mener à des failles de sécurité dans les logiciels utilisant le genérateur.

L'idée naïve consiste à conserver le numéro de processus (PID) de la dernière réinitialisation, et d'utiliser getpid() pour détecter un fork. Toutefois, comme les PID peuvent être réutilisés, il existe une petite (mal)chance en cas de double fork pour que le générateur ne soit pas réinitialisé. INHERIT_ZERO permet d'indiquer au noyau que des pages mémoires doivent être remplacées par des zéros lors d'un appel de fork. Mais cette solution n'a pas été jugée satisfaisante car elle introduit de la complexité dans le sous-système de gestion de la mémoire virtuelle pour une utilisation très limitée. À la place, la page umap contient un compteur qui est incrémenté à chaque fois que le processus fork. Ainsi, en comparant la valeur du compteur conservée dans l'état du générateur avec la valeur courante, il est possible de décider s'il faut le réinitialiser.

Ce mécanisme est en outre plus général et les 4 Kio de la page umap sont utilisés pour d'autres données. getpid(2), setproctitle(3) et clock_gettime(2) ont été adaptés pour tirer profit de cette nouveauté. Dans les faits, lorsque plus de 10 appels sont effectués sur l'une de ces fonctions, la prise en charge de upmap/kpmap est activée et les informations demandées sont obtenues via une projection en mémoire plutôt que via des appels système. Cela contribue grandement à réduire l'overhead de ces appels. À noter toutefois que gettimeofday(2) reste quant à lui un appel système, et devrait normalement le rester afin de pouvoir produire une valeur temporelle plus précise. Il est donc préférable, question performance, d'utiliser clock_gettime() plutôt que gettimeofday() lorsqu'un haut niveau de précision n'est pas nécessaire.

Ajout de reapctl(2) procctl(2)

L'appel système reapctl(2) a été ajouté par Matt Dillon, puis finalement renommé en procctl(2), afin de permettre de gérer le processus de contrôle des sous-processus.

Pour comprendre la raison du renommage, un bref historique est nécessaire. Baptiste Daroussin, membre de la core team FreeBSD et peut-être plus connu sous le pseudonyme Bapt (notamment sur LinuxFr.org), ne souhaitant pas réinventer la roue était venu demander sur le canal IRC du projet DragonFly si un équivalent des contrats Solaris existait déjà chez DragonFly. Matt Dillon ne connaissant pas les contrats Solaris, une discussion à la fois technique et sur la raison de la demande s'en est suivie, suite à quoi il proposa d'implémenter tout cela selon la discussion. « Cela me prendra 4 bonnes heures à écrire » avait-il dit, mais voilà que 2 heures plus tard, le code était poussé dans master. Pour la petite histoire, Markus Pfeiffer estimait la charge à environ 2 jours de travail pour lui, alors que Baptiste Daroussin pensait pouvoir implémenter cela en 1 mois ! Pour citer Justin Sherrill, qui s'occupe des versions de DragonFly, « Dillon is a special case : he sneezes and accidentally writes a program », que l'on pourrait traduire par « Dillon est un cas spécial : il éternue et écrit un programme accidentellement ».

Le renommage est donc intervenu par la suite, afin d'harmoniser les API de FreeBSD et DragonFly, alors que Bapt s'occupait d'intégrer cela dans FreeBSD et qu'après discussions avec d'autres développeurs FreeBSD, il a été choisi d’intégrer cela a procctl(2), apparu dans FreeBSD 10 et créé justement afin de fournir un appel système permettant de gérer les processus.

Afin d'expliquer cela, il faut savoir que sous Unix, chaque processus possède un processus père. Quand il se termine, c'est ce processus père qui va examiner son code de retour par une opération nommée reap. C'est le rôle des appels systèmes wait(2), waitpid(2), etc. Si le processus fils est toujours vivant quand le processus père termine, un nouveau père est désigné : il s'agit en général du pid 1, init. C'est ainsi que fonctionnent les démons, qui sont détachés et rattachés à init.

L'appel système procctl(2) permet de désigner le processus courant comme le processus auquel chaque descendant va être réattaché si son parent meurt avant lui. Il fonctionne récursivement, et peut être utilisé par un processus non privilégié. Il est à noter que linux possède déjà une fonctionnalité similaire en utilisant prctl depuis linux 3.4.

À terme, cette fonctionnalité pourra être utilisée pour implémenter un mécanisme similaire aux cgroups utilisés par systemd pour surveiller les démons. Le système d'init pourra lancer un processus de contrôle pour chaque démon (ce qui est très léger en ressources, d'autant plus que le code est partagé en mémoire) et designer ce processus comme le "pid 1" du sous-groupe des processus lancés par le démon. Ainsi, il est impossible que le démon échappe au contrôle d'init ; si le processus de contrôle est tué, tous les fils de celui-ci le seront aussi. De même, si le démon crash, le processus de contrôle sera en mesure de le détecter (avec l'appel système wait(2)) et de relancer le service ou de notifier l'utilisateur. Le travail pour intégrer ces mécanismes avec rcNG est en cours.

L'ajout de procctl(2) permet un début d'implémentation de svc(8), un gestionnaire de service. Celui-ci permettra donc, à terme, de créer, surveiller et gérer un environnement simple et d'exécuter une commande dans cet environnement.

Augmentation de la limite du nombre de CPU

DragonFly prend désormais en charge des systèmes possédant jusqu'à 256 CPU. La précédente limite était de 63 avec DragonFly 3.8. Des tests ont été effectués jusqu’à 255 CPU via QEMU.

Pilotes graphiques

François Tigeot a apporté de nombreuses améliorations à la pile DRM concernant le pilote i915. La plus notable est certainement l'ajout de la gestion des GPU des processeurs de la série Haswell. On note également la prise en charge de kqueue dans /dev/drm suite à un patch de Imre Vadasz qui permet notamment à OpenGL de fonctionner. Il est donc désormais possible de jouer a OpenArena ou encore Supertuxkart!

De nombreuses corrections de bugs ont été apportées au pilote drm/radeon et à son gestionnaire de mémoire ttm.

Le pilote drm/i915 est maintenant basé sur l'implémentation de Linux 3.8.13 et non plus celle de FreeBSD. De nombreuses interfaces de programmation et structures de données Linux ont été implémentées dans le noyau DragonFly afin de pouvoir réutiliser sans modification le plus de code possible du pilote i915 Linux.

Les pilotes drm suivants ont été supprimés : mach64, mga, r128, savage, sis et tdfx. Ils servaient à accélérer certaines opérations OpenGL sur d'anciens GPU datant des années 1990 à début 2000. La bibliothèque Mesa ayant abandonné leur prise en charge en 2011, ces pilotes n'avaient plus d'utilité.

Réseau

Sepherosa Ziehau a écrit un outil permettant de tester le taux de requêtes/réponse UDP. Parmi les conséquences directes, les améliorations de performances concernant UDP. À titre d'exemple, une augmentation de performance d'environ 19 % a été observée pour des requêtes et réponses UDP de 18 octets avec un Intel Core i7-3770 et une carte 10 Gigabit/s Ethernet Intel 82599ES (1,34 millions de transactions par seconde, contre 1,12 millions sans le patch).

Par ailleurs, le pilote urndis(4) a été importé depuis FreeBSD. Il permet de bénéficier de l'USB tethering ; cela signifie donc qu'un appareil disposant du partage de connexion via USB, tel un smartphone sous Android par exemple, peut être utilisé comme une carte réseau.

Le pilote if_lagg(4) a été porté depuis FreeBSD. Il permet notamment d’agréger plusieurs interfaces réseau sous la forme d'une seule interface en fournissant un mécanisme de répartition de charge entre les différents membres du groupe, ou d'avoir une interface maîtresse et des interfaces de secours qui seront utilisées automatiquement en cas de problème sur l'interface active. Il contient aussi une mise en œuvre du protocole IEEE 802.3ad (LACP), qui permet d'utiliser les mécanismes précédemment décrits en coopération avec des interfaces distantes, comme par exemple un commutateur.

Packet Filter (pf)

La majeure partie du pare-feu Packet Filter peut désormais opérer de manière parallèle.

Pilotes RAID

Le pilote mrsas(4) a été ajouté. Il permet la prise en charge des cartes RAID LSI Thunderbolt et de modèles plus récents (Invader et Fury).

Crypto

Alex Hornung a ajouté l'algorithme ChaCha, une variante améliorée du chiffrement de flux Salsa20, utilisé notamment pour BLAKE, l'un des cinq finalistes du concours du NIST pour élire l'algorithme SHA-3. ChaCha a été ajouté dans le but d'être utilisé pour le nouveau générateur de nombres pseudo-aléatoires (CSPRNG) basé sur Fortuna.
Un nouveau paramètre sysctl a d'ailleurs été ajouté afin de pouvoir choisir le générateur utilisé pour /dev/random. 3 modes sont ainsi possibles :

1. csprng, afin d'utiliser Fortuna ;
2. ibaa, pour utiliser l'ancien générateur IBAA ;
3. mixed, valeur par défaut, où les sorties des deux générateurs sont agrégées (par un XOR).

Espace utilisateur

Mises à jour diverses

Plusieurs outils ont été mis à jour dans le système de base :

• ACPICA a été mis à jour en version 20140828 ;
• GCC est passé de la version 4.7.3 à 4.7.4 ;
• GNU grep en version 2.20 ;
• Libedit est passé en version 2014-06-20 ;
• OpenSSL passe en version 1.0.1j afin de corriger plusieurs vulnérabilités (CVE-2014-3513, CVE-2014-3566, CVE-2014-3567 et CVE-2014-3568) ;
• XZ a été mis à jour en version 5.0.7 ;
• wpa_supplicant est désormais fourni dans sa version 2.1.

Ajout de rcreload

Zachary Crownover a ajouté rcreload à rcrun(8), ce qui permet de recharger la configuration d'un démon sans le redémarrer.

Import de service(8)

Depuis la première version de DragonFly, rcrun(8) est utilisé afin de gérer les scripts rc. Cependant, service(8) a été importé depuis FreeBSD, afin que les administrateurs système habitués à cet outil répandu le retrouvent également sur DragonFly.

Divers

Abandon de i386

Comme annoncé lors de la sortie de la précédente version, il n'existe désormais plus de version 32 bits de DragonFly BSD. Cela signifie qu'aucune image 32 bits n'est désormais générée et qu'aucun effort ne sera fait pour maintenir les anciennes fonctionnalités ou rendre compatibles les nouvelles fonctionnalités avec l'architecture i386. Pour rappel, plus aucun paquet binaire n'était créé pour l'architecture i386 depuis DragonFly BSD 3.8 et celle-ci ne bénéficiait déjà plus de certaines fonctionnalités présentes dans la version 64 bits, notamment en ce qui concerne la gestion de la mémoire pour les pilotes graphiques.

GNOME 3.x et Cinnamon débarquent

Les paquets pour les environnements de bureau GNOME 3.14 et Cinnamon 2.2 sont arrivés dans les dépôts. John Marino a en effet pu faire les ajustements nécessaires afin que ces environnements compilent. Pour rappel, Gnome 2 n'avait jamais compilé dans son intégralité sur DragonFly. En revanche, il reste certainement pas mal de boulot pour que ces environnements de bureaux soient pleinement utilisables. À noter que ces changements suivent ceux survenus dans les ports FreeBSD puisque les dports de DragonFly en dérivent.

Xfce et mate restent, et certainement pour un moment encore, les DE à privilégier pour une bonne expérience utilisateur.

Rust porté sous DragonFly BSD

Le langage de programmation Rust a été porté sous DragonFly BSD par Michael Neumann. Il détaille dans un article de blog le procédé qu'il a utilisé. Ce travail pourrait, selon lui, être intéressant afin de porter Rust vers d'autres BSD, notamment OpenBSD et NetBSD (Rust est déjà disponible pour FreeBSD). La difficulté du portage vient du fait que le compilateur Rust est écrit en… Rust et qu'il faut donc par conséquent passer par quelques étapes de cross-compilation depuis un système disposant déjà de Rust (Michael Neumann a utilisé Linux).

FreePascal est désormais disponible

On aurait tendance à croire que le langage Pascal, apparu pour la première fois en 1970 et mis au point par Niklaus Wirth, est devenu une relique du passé. Pourtant, un utilisateur de DragonFly semblait avoir désespérément besoin d'un compilateur pour ce langage. John Marino a réussi à porter le compilateur FreePascal sur DragonFly. Cela permet donc aux ports dépendants du compilateur fpc d'être finalement disponibles.

DragonFly se prépare a clang

DragonFly intègre deux compilateurs dans base. Pour le moment, les deux compilateurs sont GCC 4.4 et 4.7. GCC 4.4 n'étant plus vraiment utile, il est prévu de le remplacer par clang, probablement en version 3.5, pour la prochaine version de DragonFly. John Marino et Matt Dillon ont donc commencé un travail dans ce sens, afin de s'assurer que world et kernel compilent sans histoires avec clang.

Notes de mise à jour

La mise à jour vers DragonFly BSD 4.0 se fait de la manière habituelle :

cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_4_0 origin/DragonFly_RELEASE_4_0
git checkout DragonFly_RELEASE_4_0
make buildworld && make buildkernel && make installkernel && make installworld && make upgrade
reboot

Si le système a redémarré correctement, il est conseillé de faire une sauvegarde de l'initrd de secours via :

make rescue


Cette dernière étape était auparavant réalisée lors de make installworld, mais cela pouvant poser des problèmes avec le chargement du module noyau vn, cette étape a été dissociée et le module vn est désormais inclus dans le noyau.

Aller plus loin

• Site officiel (545 clics)
• Notes de version 4.0 (68 clics)
• Interview audio de Matt Dillon sur DragonFly 4.0 (BSDTalk) (72 clics)