URL: https://linuxfr.org/news/dragonfly-bsd-4-0 Title: DragonFly BSD 4.0 Authors: Rolinh ZeroHeure, Naha, BAud, Enj0lras, palm123, François Tigeot, M5oul, grim7reaper, Benoît Sibaud, Nÿco et TsyMiroro MDG Date: 2014年08月22日T13:28:26+02:00 License: CC By-SA Tags: bsd, dragonflybsd et niklaus_wirth Score: 60 Après 3 RC, DragonFly BSD 4.0 a été [annoncée](http://lists.dragonflybsd.org/pipermail/users/2014-November/187551.html) 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. ![dragonflybsd](http://www.dragonflybsd.org/images/small_logo.png) ---- [Site officiel](http://www.dragonflybsd.org/) [Notes de version 4.0](http://www.dragonflybsd.org/release40/) [Interview audio de Matt Dillon sur DragonFly 4.0 (BSDTalk)](https://ia802605.us.archive.org/9/items/bsdtalk248/bsdtalk248.ogg) ---- ![DragonFly BSD Xfce](http://pix.toile-libre.org/upload/original/1415988077.png "DragonFly BSD sur un Thinkpad T420") _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](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270857.html) [été](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270858.html) [ajoutés](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270860.html). Ces deux périphériques projetables en mémoire avec [mmap(2)](http://leaf.dragonflybsd.org/cgi/web-man?command=mmap§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=getpid§ion=2), [setproctitle(3)](http://leaf.dragonflybsd.org/cgi/web-man?command=setproctitle§ion=3) et [clock_gettime(2)](http://leaf.dragonflybsd.org/cgi/web-man?command=clock_gettime§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=gettimeofday§ion=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é](http://lists.dragonflybsd.org/pipermail/commits/2014-November/307394.html) [ajouté](http://lists.dragonflybsd.org/pipermail/commits/2014-November/307395.html) par Matt Dillon, puis finalement [renommé](http://lists.dragonflybsd.org/pipermail/commits/2014-November/343844.html) en [procctl(2)](http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=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](//linuxfr.org/users/grom) (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)](http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=wait§ion=2), [waitpid(2)](http://leaf.dragonflybsd.org/cgi/web-man?command=waitpid§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=wait§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=2) permet [un début d'implémentation](http://lists.dragonflybsd.org/pipermail/commits/2014-November/343845.html) de [svc(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=svc§ion=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](http://lists.dragonflybsd.org/pipermail/commits/2014-July/270349.html) [en charge](http://lists.dragonflybsd.org/pipermail/commits/2014-July/270355.html) 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](http://gitweb.dragonflybsd.org/dragonfly.git/commit/62e5f8e83d1965557404f130b11aa59d4cae0868) 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](http://lists.dragonflybsd.org/pipermail/commits/2014-November/343821.html) 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](http://lists.dragonflybsd.org/pipermail/commits/2014-June/270159.html) un outil permettant de tester le taux de requêtes/réponse UDP. Parmi les conséquences directes, [les améliorations de performances](http://lists.dragonflybsd.org/pipermail/commits/2014-June/270160.html) 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](http://ark.intel.com/products/65719) 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=urndis§ion=4) a été [importé](http://lists.dragonflybsd.org/pipermail/commits/2014-July/270377.html) 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=if_lagg§ion=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](http://fr.wikipedia.org/wiki/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](http://lists.dragonflybsd.org/pipermail/commits/2014-June/270300.html). Pilotes RAID ------------ Le pilote [mrsas(4)](http://leaf.dragonflybsd.org/cgi/web-man?command=mrsas§ion=4) a [été ajouté](http://lists.dragonflybsd.org/pipermail/commits/2014-June/270246.html). 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](http://lists.dragonflybsd.org/pipermail/commits/2014-July/270429.html), 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)](http://lists.dragonflybsd.org/pipermail/commits/2014-July/270430.html) basé sur [Fortuna](http://fr.wikipedia.org/wiki/Fortuna_(cryptographie)). 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 ; 1. ibaa, pour utiliser l'ancien générateur IBAA ; 1. mixed, valeur par défaut, où les sorties des deux générateurs sont agrégées (par un [XOR](http://fr.wikipedia.org/wiki/Fonction_OU_exclusif)). Espace utilisateur ================== Mises à jour diverses --------------------- Plusieurs outils ont été mis à jour dans le système de base : - ACPICA a été [mis à jour](http://lists.dragonflybsd.org/pipermail/commits/2014-August/270685.html) en version 20140828 ; - GCC est passé de la version 4.7.3 [à 4.7.4](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270832.html) ; - GNU grep [en version 2.20](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270835.html) ; - Libedit est passé [en version 2014年06月20日](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270848.html) ; - OpenSSL [passe en version 1.0.1j](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270870.html) 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](http://lists.dragonflybsd.org/pipermail/commits/2014-October/270833.html) en version 5.0.7 ; - wpa_supplicant est désormais fourni dans sa version 2.1. ## Ajout de rcreload Zachary Crownover a [ajouté](http://lists.dragonflybsd.org/pipermail/commits/2014-July/270455.html) rcreload à [rcrun(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=rcrun§ion=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=rcrun§ion=8) est utilisé afin de gérer les scripts rc. Cependant, [service(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=service§ion=8) a été [importé](http://lists.dragonflybsd.org/pipermail/commits/2014-June/343003.html) 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](/news/dragonfly-bsd-3-8), 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](http://fr.wikipedia.org/wiki/Rust_(Mozilla)) a été porté sous DragonFly BSD par Michael Neumann. Il détaille dans [un article de blog](http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/) 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](http://fr.wikipedia.org/wiki/Pascal_(langage)), apparu pour la première fois en 1970 et mis au point par [Niklaus Wirth](http://fr.wikipedia.org/wiki/Niklaus_Wirth), est devenu une relique du passé. Pourtant, un utilisateur de DragonFly semblait [avoir désespérément besoin](http://lists.dragonflybsd.org/pipermail/users/2014-November/167968.html) d'un compilateur pour ce langage. John Marino a [réussi à porter](http://lists.dragonflybsd.org/pipermail/users/2014-November/187534.html) 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é](http://lists.dragonflybsd.org/pipermail/commits/2014-November/380379.html) [un travail](http://lists.dragonflybsd.org/pipermail/commits/2014-November/380351.html) 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 : ```sh 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](http://lists.dragonflybsd.org/pipermail/commits/2014-August/270673.html) [des problèmes](http://lists.dragonflybsd.org/pipermail/users/2014-August/128822.html) avec le chargement du module noyau vn, cette étape a été dissociée et le module vn est désormais [inclus dans le noyau](http://lists.dragonflybsd.org/pipermail/commits/2014-August/270672.html).

AltStyle によって変換されたページ (->オリジナル) /