tag:linuxfr.org,2005:/tags/mesh/publicLinuxFr.org : les contenus étiquetés avec « mesh »2024-01-17T08:15:08+01:00/favicon.pngtag:linuxfr.org,2005:Bookmark/77892024-01-15T19:55:56+01:002024-01-17T08:14:19+01:00Réseau mesh 10Gbps basé sur USB4, pour $47.98<a href="https://fangpenlin.com/posts/2024/01/14/high-speed-usb4-mesh-network/">https://fangpenlin.com/posts/2024/01/14/high-speed-usb4-mesh-network/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/134508/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/aurelieng/liens/reseau-mesh-10gbps-base-sur-usb4-pour-47-98#comments">ouvrir dans le navigateur</a>
</p>
aurelhttps://linuxfr.org/nodes/134508/comments.atomtag:linuxfr.org,2005:Post/401862019-05-31T22:59:34+02:002019-05-31T22:59:34+02:00Logiciel de photogrammétrie ?<p>Bonjour,</p>
<p>Je recherche un logiciel de photogrammétrie pour modéliser des objets 3D (et éviter ainsi d'avoir à le faire à la main, principalement, mais aussi parce que je répare pas mal de trucs avec mon impression 3D). Je voulais opter pour un scanner 3D, mais je n'ai pas la place pour le moment. Je me suis dit que la photogrammétrie pourrait être utile.</p>
<p>Seulement, je n'ai rien trouvé de facile à installer (dès qu'il y a compilation, il y a erreur, en gros), de fonctionnel sur mon système (je n'ai pas CUDA ou de CG nvidia). Auriez-vous des conseils ? J'ai testé Micmap, colmap, meshroom, mais je n'ai soit pas réussi à les installer, soit il faut CUDA.</p>
<p>Merci ! :)</p>
<div><a href="https://linuxfr.org/forums/general-cherche-logiciel/posts/logiciel-de-photogrammetrie.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/117364/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/general-cherche-logiciel/posts/logiciel-de-photogrammetrie#comments">ouvrir dans le navigateur</a>
</p>
Stinouffhttps://linuxfr.org/nodes/117364/comments.atomtag:linuxfr.org,2005:Diary/342222013-08-17T20:20:07+02:002013-08-17T20:20:07+02:00cjdns / hyperboria : réseau décentralisé et sécuriséLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<p>Pour faire bref, c'est un darknet avec les caractéristiques suivantes :</p>
<ul>
<li>réseau pair à pair expérimental</li>
<li>assez simple à mettre en œuvre</li>
<li>créé une interface réseau TUN (tunnel) IPv6 avec une IP privée</li>
<li>communications chiffrées </li>
<li>contrairement à TOR/I2P/FreeNet, l'anonymat "pur et dur" n'est pas le but premier. Le but est plutôt de créer un réseau privé entre tiers de confiance.</li>
<li>après installation de son propre nœud cjdns, il faut demander à un utilisateur déjà dans le réseau les coordonnées de son nœud, sur le canal IRC du projet, afin de pouvoir rejoindre soi-même le réseau. Une fois dans le réseau, on a accès à quelques sites/services (voir hyperboria.net).</li>
<li>On peut bien sûr offrir soi-même des services sur son nœud personnel.</li>
</ul><p>Quelques informations plus techniques selon ce site : <a href="http://wiki.reseaulibre.ca/documentation/monitoring/documentationPertinente/">http://wiki.reseaulibre.ca/documentation/monitoring/documentationPertinente/</a></p>
<blockquote>
<p>CJDNS est un protocole de routage multicouches sécurisé et décentralisé qui vise à combler les failles des protocoles conçus il y a plus de trente ans et qui constituent l'architecture fondamentale de l'internet moderne. CJDNS cherche notamment à résoudre efficacement le problème de la taille des tables de routage par une utilisation judicieuse des tables de hashage décentralisée. Son architecture permet entre autre le relais de paquets sans lecture mémoire grâce à des entêtes contenant le chemin jusqu'au prochain router. Le routage se fait par étapes successives qui visent à s'approcher de la destination en utilisant une table routage restreinte obtenue par des demande de type “recherche” aux voisins connus. Le protocole offre aussi une sécurité complète grâce à un mécanisme d'encryption incorporé au protocole. L'authentification est basée sur SHA-256. Ce protocole est réactif, mais son modèle de hashage décentralisé simplifie grandement la recherche de la destination. Par contre, la couche de sécurité supplémentaire réduit quelque peu sa performance. On notera aussi que CJDNS est capable d'opérer via tunnel et que les adresses qu'il génère n'entrent pas en conflit avec l'internet traditionnel puisqu'elles se situent dans le bloc. Il est important de noter que ce protocole ne comporte pas de processus de découverte de nouveaux nœuds, ce qui signifie qu'un nouveau nœud doit s'arrimer manuellement au réseau à travers un pair. Ce protocole est encore relativement récent, le statut courant est "pré-alpha". Parmi les projets existants qui utilisent CJDNS, on notera Meshnet et Hyperboria, ce dernier aspirant à rien de moins qu'être le successeur de l'internet.</p>
</blockquote>
<p>Aucune documentation officielle en français pour le moment…</p>
<p>Site officiel du projet avec instructions d'installation<br><a href="https://github.com/cjdelisle/cjdns#cjdns">https://github.com/cjdelisle/cjdns#cjdns</a></p>
<p>Présentation du principe par l'auteur (Caleb James DeLisle)<br><a href="https://raw.github.com/cjdelisle/cjdns/master/doc/Whitepaper.md">https://raw.github.com/cjdelisle/cjdns/master/doc/Whitepaper.md</a></p>
<p>L'article sur wikipedia<br><a href="https://en.wikipedia.org/wiki/Cjdns">https://en.wikipedia.org/wiki/Cjdns</a></p>
<p>Un wiki dédié<br><a href="https://wiki.projectmeshnet.org/Getting_Started">https://wiki.projectmeshnet.org/Getting_Started</a></p>
<p>La FAQ<br><a href="https://wiki.projectmeshnet.org/FAQ">https://wiki.projectmeshnet.org/FAQ</a></p>
<p>Le portail Hyperboria.net<br><a href="http://hyperboria.net">http://hyperboria.net</a></p><div><a href="https://linuxfr.org/users/agentsteel/journaux/cjdns-hyperboria-reseau-decentralise-et-securise.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/99384/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/agentsteel/journaux/cjdns-hyperboria-reseau-decentralise-et-securise#comments">ouvrir dans le navigateur</a>
</p>
AgentSteelhttps://linuxfr.org/nodes/99384/comments.atomtag:linuxfr.org,2005:Diary/324972012-04-23T09:29:16+02:002012-04-23T09:29:16+02:00Serval, ou quand le centre du reseau téléphonique disparaitLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<p>Je suis récemment tombé sur Serval, logiciel pour les téléphones mobiles pour s'affranchir des opérateurs télécom.</p>
<p>Le principe est simple. Chaque téléphone est potentiellement un noeud de réseau souple et mouvant. Un téléphone est capable de recevoir et de renvoyer. <br />
Ainsi rien ne devrait empêcher deux téléphones dans la même zone de communiquer directement sans passer par une borne de l'opérateur. En y réfléchissant un peu plus, on se rend compte qu'un téléphone pourrait faire le relais de communication, sans y participer activement. Quand il est passif, il peut servir de noeud relais et donc étendre la zone de couverture du réseau mouvant.</p>
<p>C'est tout le but du projet <a href="http://www.servalproject.org/">Serval</a>. Les implications économiques (limitations de l'utilisation des réseaux télécom propriétaire) et politiques (surveiller des communications centralisées, c'est plus facile que sur un ressaut instable) sont importantes et mérite notre attention de libriste</p>
<p>Pour l'anecdote, parmi les contributeurs on trouve des étudiants de l'INSA et parmi les mécènes on trouve la fondation Shuttleworth.</p>
<ul><li><a href="http://www.servalproject.org/">Projet Serval</a></li>
</ul><div><a href="https://linuxfr.org/users/fdf/journaux/serval-ou-quand-le-centre-du-reseau-telephonique-disparait.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/90406/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/fdf/journaux/serval-ou-quand-le-centre-du-reseau-telephonique-disparait#comments">ouvrir dans le navigateur</a>
</p>
FDFhttps://linuxfr.org/nodes/90406/comments.atomtag:linuxfr.org,2005:Diary/315312011-08-30T21:55:37+02:002011-08-30T21:55:37+02:00Commotion, un nouveau réseau meshLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<h3 id="toc_0">ou les révolutions informatiques selon Le Monde</h3>
<p>Voici le nouveau <em>buzz</em> du moment : <a href="http://tech.chambana.net/projects/commotion">Commotion</a>, un réseau mesh. Outre un nom tout pourri (mais moins que <a href="http://fr.wikipedia.org/wiki/Netsukuku" title="Définition Wikipédia">Netsukuku</a>), Commotion a surtout profité d'un <a href="http://www.lemonde.fr/technologies/article/2011/08/30/commotion-le-projet-d-un-internet-hors-de-tout-controle_1565282_651865.html">article sur Le Monde</a>.</p>
<p>Alors, qu'est-ce qu'il a de particulier ce truc ? Rien. C'est un réseau mesh, en wifi, avec les mêmes avantages et inconvénients que les autres. Ce qui est rigolo, c'est la façon dont le présente Le Monde. À les lire, on a l'impression que c'est une véritable révolution, que c'est la solution ultime, anonyme, décentralisée, sécurisé, incontrôlable, etc etc, qui nous permettra de combler tous les défauts d'Internet. Ok, tout ça ça a l'air bien, mais quand je vois que j'ai du mal à me connecter en wifi à mon routeur qui est à 20 mètres juste parce qu'il y a 3 murs (assez épais certes) entre lui et moi, je me pose des questions.</p>
<p>Et puis il y a autre chose qui me fait tiquer. En lisant l'article on a l'impression que jamais personne n'avait pensé à ça avant Commotion. Et <a href="http://fr.wikipedia.org/wiki/B.A.T.M.A.N." title="Définition Wikipédia">B.A.T.M.A.N.</a> ? Et <a href="http://fr.wikipedia.org/wiki/Netsukuku" title="Définition Wikipédia">Netsukuku</a> ? Et tous les autres ? Ils n'ont jamais existé ?</p>
<p>Ah oui, j'oubliais, ils n'ont pas 2,3 M$ donnés pas Google et 2 M$ donnée par l'état américain. Pourquoi ? Bonne question.</p><div><a href="https://linuxfr.org/users/erdnaxeli/journaux/commotion-un-nouveau-r%C3%A9seau-mesh.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/87231/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/erdnaxeli/journaux/commotion-un-nouveau-r%C3%A9seau-mesh#comments">ouvrir dans le navigateur</a>
</p>
erdnaxelihttps://linuxfr.org/nodes/87231/comments.atomtag:linuxfr.org,2005:Post/294662010-12-08T15:35:43+01:002010-12-08T15:35:43+01:00Norme 802.11S et Mesh
Bonjour !<br />
<br />
Je suis actuellement à la recherche d'informations concernant le Wifi Mesh ( norme 802.11S). A vrai dire j'ai déjà moulte documentations mais je ne saisis pas la différence entre le mode ad hoc et le le Mesh.<br />
<br />
Est ce que quelqu'un serait capable de m'éclairer ?<br />
<br />
Je lui en serais très reconnaissante :-)<br />
<br />
Elise<div><a href="https://linuxfr.org/forums/general-general/posts/norme-80211s-et-mesh.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/83956/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/general-general/posts/norme-80211s-et-mesh#comments">ouvrir dans le navigateur</a>
</p>
Elisehttps://linuxfr.org/nodes/83956/comments.atomtag:linuxfr.org,2005:News/275582010-11-08T01:39:59+01:002010-11-08T01:39:59+01:00Une alternative à Internet : Netsukuku<div>Il existe plusieurs projets de réseaux alternatifs permettant une plus grande décentralisation et une meilleure résistance à la censure et à l'ingérence d'un tiers sur le réseau. Parmi ceux-ci, plusieurs fonctionnent selon le principe d'une couche d'abstraction supplémentaire au-dessus d'Internet. On peut citer FreeNet et I2P, par exemple.
<br />
<br />
Netsukuku est radicalement différent. Ce réseau ne fonctionne pas à partir des couches Internet existantes. En fait, ce système remplace la couche 3 du modèle OSI, et possède donc ses propres protocoles de routage, ainsi que son propre algorithme pour l'attribution des noms de domaines. On peut donc considérer Netsukuku non pas comme une contribution à Internet, mais plutôt comme une alternative, voire même comme un concurrent.</div><ul><li>lien nᵒ 1 : <a title="http://en.wikipedia.org/wiki/Netsukuku" hreflang="en" href="https://linuxfr.org/redirect/69718">Page wikipedia sur Netsukuku</a></li><li>lien nᵒ 2 : <a title="http://netsukuku.freaknet.org/" hreflang="en" href="https://linuxfr.org/redirect/69719">Site officiel</a></li><li>lien nᵒ 3 : <a title="http://netsukuku.freaknet.org/?pag=faq" hreflang="en" href="https://linuxfr.org/redirect/69720">La FAQ du projet</a></li></ul><div>À la base Netsukuku était un projet visant à exploiter pleinement toutes les possibilités du mode de transmission WiFi. L'objectif était de permettre à un réseau sans fil de se former spontanément, sans qu'aucune intervention humaine ne soit requise. Un tel réseau devait être capable de résister à la disparition où à l'apparition impromptue de nœuds sur le réseau.
<br />
<br />
Le fonctionnement de Netsukuku repose sur trois concepts :
<br />
<ul><li>Une structure topologique hiérarchisée : chaque nœud fait partie d'un groupe de 256 nœuds. Chaque groupe fait partie d'un « ggroup » de 256 groupes. Chaque ggroup fait partie d'un « gggroup ». Etc. Au final, chaque nœud se voit attribué une adresse de 128 bits, soit autant que pour IPv6.
<br />
</li><li>Un protocole de routage spécifique : QSPN, pour "Quantum Shortest Path Netsukuku".
<br />
</li><li>Un système de résolution d'adresse : ANDNA, pour « A Netsukuku Domain Name Architecture ». Son fonctionnement, délicat à résumer ici, permet notamment l'utilisation de paire de clefs pour l'authentification des nœuds.
<br />
</li></ul>Netsuku est donc un réseau ad hoc entièrement décentralisé et automatisé. Il procure les mêmes fonctions de base d'internet, à savoir le routage et la résolution de noms de domaine, de telle sorte que les applications internet standards devraient pouvoir tourner sur Netsukuku.
<br />
<br />
Une implémentation en python, accompagnée de code C pour les fonctions de bas niveau, a été publiée en octobre 2010.</div><div><a href="https://linuxfr.org/news/une-alternative-a-internet-netsukuku.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/26473/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/une-alternative-a-internet-netsukuku#comments">ouvrir dans le navigateur</a>
</p>
grondiluhttps://linuxfr.org/nodes/26473/comments.atomtag:linuxfr.org,2005:News/264782010-02-25T07:01:18+01:002010-02-25T07:01:18+01:00Nouvelle version 2.6.33 du noyau Linux<div>La sortie de la version stable 2.6.33 du noyau Linux <a href="http://lkml.org/lkml/2010/2/24/301">vient d'être annoncée</a> par Linus Torvalds. Le nouveau noyau est - comme d'habitude - téléchargeable sur les serveurs du site <a href="http://kernel.org/">kernel.org</a>.
<br />
<br />
Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence libre <a href="http://creativecommons.org/licenses/by-sa/3.0/deed.fr">CC BY-SA</a>).
<br />
<br />
PS : Je tiens à remercier tout particulièrement Frédéric Weisbecker, premier contributeur en terme de patchs sur le noyau 2.6.33, qui a accepté de donner un peu de son temps pour répondre à mes questions. Vous trouverez un entretien en fin de dépêche.
<br />
<br />
PS 2 : Merci aussi aux relecteurs/correcteurs de cette (longue) dépêche.</div><ul><li>lien nᵒ 1 : <a title="http://kernelnewbies.org/Linux_2_6_33" hreflang="en" href="https://linuxfr.org/redirect/65564">Les nouveautés du noyau 2.6.33</a></li><li>lien nᵒ 2 : <a title="http://lwn.net/Articles/365443/" hreflang="en" href="https://linuxfr.org/redirect/65565">Le bilan des ajouts partie 1</a></li><li>lien nᵒ 3 : <a title="http://lwn.net/Articles/366436/" hreflang="en" href="https://linuxfr.org/redirect/65566">Le bilan des ajouts partie 2</a></li><li>lien nᵒ 4 : <a title="http://www.h-online.com/open/features/2-6-33-Tracking-890639.html" hreflang="en" href="https://linuxfr.org/redirect/65567">Les articles de H-Online</a></li><li>lien nᵒ 5 : <a title="http://linuxfoundation.org/collaborate/lwf" hreflang="en" href="https://linuxfr.org/redirect/65568">Les prévisions pour l'avenir de Linux</a></li></ul><div><h2><a name="sommaire"></a>Le sommaire...</h2><ul><li><a href="#test">La phase de test</a>
<br />
<ul><li><a href="#rc1">RC-1</a>
<br />
</li><li><a href="#rc3">RC-3</a>
<br />
</li><li><a href="#rc4">RC-4</a>
<br />
</li><li><a href="#rc5">RC-5</a>
<br />
</li><li><a href="#rc6">RC-6</a>
<br />
</li><li><a href="#rc7">RC-7</a>
<br />
</li><li><a href="#rc8">RC-8</a></li></ul>
<br />
</li><li><a href="#nouveautes">Les nouveautés</a>
<br />
<ul><li><a href="#drbd">Stockage distribué DRBD</a>
<br />
</li><li><a href="#cookie">Transaction TCP par cookie</a>
<br />
</li><li><a href="#ramzswap">Compactage mémoire ramzswap</a>
<br />
</li><li><a href="#iobloc">Contrôleur IO-Block</a>
<br />
</li><li><a href="#android">Pilotes Android retirés du noyau</a>
<br />
</li><li><a href="#nouveau">Intégration de Nouveau</a></li></ul>
<br />
</li><li><a href="#en_bref">En bref</a>
<br />
<ul><li><a href="#radeon">Pilote Radeon</a>
<br />
</li><li><a href="#devicemapper">Snapshot dans le device-mapper</a>
<br />
</li><li><a href="#better-io">Entrées/sorties asynchrones</a>
<br />
</li><li><a href="#anticipatory">Suppression d'un ordonnanceur IO</a>
<br />
</li><li><a href="#reiserfs">ReiserFS sans BKL</a>
<br />
</li><li><a href="#sysctl">Appel système sysctl</a>
<br />
</li><li><a href="#tracing">Tracing</a>
<br />
</li><li><a href="#recvmmsg">Appel système recvmmsg</a>
<br />
</li><li><a href="#LSM-hooks">Crochets LSM</a>
<br />
</li><li><a href="#optimisation">Optimisation Ext2/3</a>
<br />
</li><li><a href="#batman">Protocole BATMAN</a>
<br />
</li><li><a href="#loongson">Loongson 2F</a>
<br />
</li><li><a href="#powerpc">PowerPC et consoles de jeux</a>
<br />
</li><li><a href="#tiny">Tiny RCU</a>
<br />
</li><li><a href="#nilfs">NILFS</a>
<br />
</li><li><a href="#xfs">XFS</a>
<br />
</li><li><a href="#kvm">KVM</a>
<br />
</li><li><a href="#hyper-v">Pilote Microsoft Hyper V</a></li></ul>
<br />
</li><li><a href="#bilan">Le bilan en chiffres</a>
<br />
</li><li><a href="#fweisbec">Questions/Réponses avec Frédéric Weisbecker</a>
<br />
</li><li><a href="#pour_la_suite">Pour la suite</a>
<br />
</li></ul><h2><a name="test"></a>La phase de test (<a href="#sommaire">↑</a>)</h2><h3><a name="rc1"></a>RC-1</h3>
<br />
La version <a href="http://lwn.net/Articles/367241/">RC-1</a> a été annoncée par Linus le 17 décembre dernier :
<br />
<br />
« <i>Bon la période de merge est fermée et la RC-1 est maintenant disponible.
<br />
En parlant de période de merge, il y a eu un _paquet_ de branches qui n'ont envoyé leur demande de merge que très tard. Je suis habitué à avoir un dernier jour de la période vraiment très chargé, mais cette fois, ça a duré deux jours. Bien pire que d'habitude.
<br />
La période d'ouverture de deux semaines n'est <b>pas</b> supposée être "une demande de merge après un silence de treize jours". En fait, je pense que la prochaine fois, je vais réduire la phase à onze ou douze jours. Ainsi, les gens qui auront essayé de jouer au plus fin en envoyant leur demande au dernier moment auront une sale surprise. Ils seront obligés d'attendre le 2.6.35.
<br />
En dehors de ce grognement cela a été une phase assez classique, je pense. Les changements se répartissent en :<ul><li>1/3 dans la branche staging
<br />
</li><li>1/3 "le reste des pilotes"
<br />
</li><li>1/3 "tout le reste"</li></ul>avec environ la moitié de ce "tout le reste" final qui concerne les diverses architectures et l'autre moitié les autres trucs (micrologiciels, systèmes de fichiers, réseau, etc.).
<br />
Les ajouts notables ? Personnellement, j'aime la façon dont j'ai enfin réussi à merger le code de <a href="http://nouveau.freedesktop.org/wiki/">Nouveau</a> par exemple.
<br />
Merci de tester à fond cette RC-1, comme ça nous commencerons à avoir une idée au sujet des inévitables régressions</i> ».
<br />
<h3><a name="rc2"></a>RC-2</h3>
<br />
C'est pile le jour de Noël que Linus a mis a disposition la version <a href="http://lwn.net/Articles/368097/">RC-2</a> :
<br />
<br />
« <i>Joyeux Noël… ou quoi que vous célébriez aujourd'hui/demain.
<br />
Et, si vous ne célébrez rien du tout et que vous crevez d'ennui assis dans votre cave sombre, alors vous pouvez au moins essayer la dernière RC. C'est toujours mieux que de se morfondre sans rien faire.
<br />
Et si vous fêtez un truc, mais que vous avez une indigestion de jambon (ou que vous en avez marre de perdre tous vos vêtements dans des parties de strip et d'être la risée de tout le monde) alors faites une pause, compilez un noyau et essayez-le.
<br />
Parce que, si votre pantalon ne vous va peut-être plus pendant un mois, le nouveau noyau, lui, sera peut-être bien adapté à votre ordinateur.
<br />
<br />
J'aurais apprécié une RC-2 plus petite mais j'ai vu pire, donc je ne vais pas me plaindre.
<br />
Et maintenant je suis off, car je vais aller peler des patates. Et les manger ensuite.
<br />
Amusez-vous.</i> ».
<br />
<h3><a name="rc3"></a>RC-3</h3>
<br />
Après cette interruption culinaire et digestive, il a fallu attendre le 5 janvier pour la <a href="http://lwn.net/Articles/368827/">RC-3</a> :
<br />
<br />
« <i>Tout a été tranquille du fait des vacances et la RC-3 est raisonnablement petite en dépit de son retard de quelques jours. La plupart des changements sont triviaux, mais il y a eu des problèmes sur <a href="http://fr.wikipedia.org/wiki/Ext4">ext4</a> et <a href="http://fr.wikipedia.org/wiki/ReiserFS">ReiserFS</a> dans la RC-2, avec un peu de chance tout est corrigé maintenant.
<br />
Le changement qui est peut-être le plus notable n'est pas une modification de code, mais le fait de recommander maintenant officiellement la "nouvelle" pile <a href="http://fr.wikipedia.org/wiki/FireWire">firewire</a> par rapport à l'ancienne.
<br />
Espérons que l'une des raisons pour expliquer ce calme est que tout est réellement stable. Essayez-le !</i> ».
<br />
<h3><a name="rc4"></a>RC-4</h3>
<br />
Une semaine plus tard, c'est la version <a href="http://lwn.net/Articles/369615/">RC-4</a> qui a été annoncée :
<br />
<br />
« <i>Hmm. Une version bizarre. Il y a environ 40% des patchs qui concernent DRM (surtout <a href="http://fr.wikipedia.org/wiki/Nouveau_%28informatique%29">nouveau</a> et <a href="http://fr.wikipedia.org/wiki/RadeonHD">radeon</a>, qui sont en staging, donc c'est un peu moins effrayant qu'il ne semble. Mais il y a aussi des trucs sur i915). C'est assez inhabituel pour autant que je sache.</i> ».
<br />
<h3><a name="rc5"></a>RC-5</h3>
<br />
La version <a href="http://lwn.net/Articles/370711/">RC-5</a> a été annoncée le 21 janvier :
<br />
<br />
« <i>Je ne pense pas qu'il y ait quoi que ce soit de renversant là-dedans, mais la modification du pilote <a href="http://fr.wikipedia.org/wiki/Kernel-based_mode-setting">KMS</a> i915 est assez importante. Notamment, si vous avez un port eDP ("embedded DisplayPort" - Je pense que c'est une fonction que vous retrouvez dans un nouvel iMac), eh bien maintenant il fonctionne. Mais aussi, si vous aviez des problèmes de tremblement d'image du fait de la réduction de fréquence <a href="http://fr.wikipedia.org/wiki/Low_Voltage_Differential_Signaling">LVDS</a> (ça économise du courant, mais c'est maintenant désactivé par défaut jusqu'à ce que ce problème soit résolu).
<br />
À part ça, c'est un bon paquet de petites corrections.</i> ».
<br />
<h3><a name="rc6"></a>RC-6</h3>
<br />
C'est le 29 janvier que Linus a annoncé la disponibilité de la version de test <a href="http://lwn.net/Articles/371895/">RC-6</a> :
<br />
<br />
« <i>Hmm. À peu près 50% des patchs sont sur les diverses architectures et 40% sur les pilotes. Le reste concerne principalement les systèmes de fichiers et le réseau.
<br />
Nous arrivons dans cette étape du cycle ou tout devrait plus ou moins "juste marcher" et où les gens qui découvrent des régressions devraient commencer à beugler très fort pour que ce soit corrigé</i> ».
<br />
<h3><a name="rc7"></a>RC-7</h3>
<br />
Lors de la mise à disposition de la version <a href="http://lwn.net/Articles/373332/">RC-7</a> le 6 février, Linus a indiqué qu'il restait encore du travail à faire :
<br />
<br />
« <i>Je dois admettre que j'aurais souhaité avoir moins de régressions à cette étape du processus. J'incite les développeurs à aller regarder sur <a href="http://article.gmane.org/gmane.linux.kernel.wireless.general/46197">la liste</a> juste pour voir s'ils reconnaissent des régressions qui leur semblent familières. Prendre quelques minutes pour regarder cette liste et se dire "Hmm, peut-être que je connais celle-là" est une bonne idée.
<br />
Mais nous avons certainement corrigé un certain nombre de choses, et ça fait une semaine donc voilà la RC-7. J'aimerais pouvoir dire que c'est la dernière RC, mais j'en doute fortement et il y en aura presque certainement au moins une autre</i> ».
<br />
<h3><a name="rc8"></a>RC-8</h3>
<br />
Enfin, le 13 février, Linus a annoncé la dernière version candidate avant la sortie du noyau officiel :
<br />
« <i>Je pense que ce sera la dernière RC de ce cycle, donc s'il vous plaît testez-là bien. Un certain nombre de régressions devraient être corrigées et - même si la liste des régressions ne me rend pas _content_ - au moins nous n'avons pas ces sales trucs qui m'inquiétaient avant la RC-7</i> ».
<br />
<h2><a name="nouveautes"></a>Les nouveautés (<a href="#sommaire">↑</a>)</h2><h3><a name="drbd"></a>Stockage distribué DRBD</h3>
<br />
Le système de stockage distribué <a href="http://lwn.net/Articles/329543/">DRBD</a> (Distributed Replicated Block Device) fait maintenant partie du noyau Linux depuis cette version 2.6.33.
<br />
Écrit à l'origine par Philipp Reisner dans le cadre de son master d'informatique de <a href="http://fr.wikipedia.org/wiki/Universit%C3%A9_technique_de_Vienne">l'Université technique de Vienne</a> ce système de stockage est développé par la société <a href="http://www.linbit.com/en/">LINBIT</a> qu'il a fondée en 2001.
<br />
DRBD peut être compris comme un équivalent réseau du système de réplication <a href="http://fr.wikipedia.org/wiki/RAID_%28informatique%29#RAID_1_:_Disques_en_miroir">RAID 1</a> (disques durs en miroir) et cela permet de construire des serveurs répartis de <a href="http://fr.wikipedia.org/wiki/Haute_disponibilit%C3%A9">haute disponibilité</a> avec des systèmes de fichiers distribués de type <a href="http://fr.wikipedia.org/wiki/Global_File_System">GFS</a> ou <a href="http://en.wikipedia.org/wiki/OCFS">OCFS2</a>.
<br />
Les périphériques de stockages utilisent en interne des <a href="http://en.wikipedia.org/wiki/Block_device#Block_devices">blocs de données</a>. Ce sont ces blocs de bas niveau qui sont répliqués par DRBD sur plusieurs machines de façon automatique. Cette réplication peut se faire de façon synchrone (un bloc est considéré comme répliqué uniquement quand il a été écrit en local, envoyé vers le disque du nœud distant et que ce nœud distant a confirmé qu'il était correctement écrit) ou bien de façon asynchrone (un bloc est considéré comme répliqué quand il a été écrit en local et qu'il a juste été envoyé vers le nœud distant, sans confirmation en retour). On voit bien que la méthode synchrone est plus robuste mais qu'elle dépend de la vitesse du réseau. La méthode asynchrone peut impliquer des pertes de données (sans perte de cohérence toutefois) mais elle est utile pour des nœuds séparés par de longues distances avec une latence importante. Pour avoir une idée des performances <a href="http://www.drbd.org/home/wiki/?tx_drwiki_pi1[keyword]=performance">ce test</a> indique que la version synchrone (c'est le "protocole C" en langage DRBD) tombe à 163,8 Mo/s par rapport aux 239,8 Mo/s de la version asynchrone.
<br />
<br />
Actuellement DRBD ne supporte que deux nœuds mais cette limitation sera supprimée par la suite. Il y a plusieurs avantages de cette technique de réplication au niveau du bloc de données par rapport à une classique grappe de serveurs (<a href="http://fr.wikipedia.org/wiki/Grappe_de_serveurs">cluster</a>).
<br />
Tout d'abord les opérations de lecture de données, qui sont prépondérantes, s'effectuent purement en local puisque les données sont répliquées sur tous les nœuds. Plus besoin de passer par le goulet d'étranglement que constitue le réseau.
<br />
Ensuite et surtout la réplication de données est naturellement plus robuste que le simple partage qui est souvent utilisé dans les grappes de serveurs. La perte du réseau entre deux nœuds ne risque pas de provoquer de situation de conflit ou d'accaparement des ressources par les nœuds qui croient chacun que l'autre n'est plus actif.
<br />
Pour ceux qui désirent se plonger dans les entrailles techniques du système un <a href="http://www.drbd.org/fileadmin/drbd/publications/drbd8_wpnr.pdf">fichier PDF explicatif</a> est disponible ainsi qu'un <a href="http://www.drbd.org/users-guide/">guide d'utilisation</a> détaillé.
<br />
<br />
Le patch externe implémentant DRBD a été soumis initialement sur la liste de diffusion du noyau en <a href="http://lwn.net/Articles/242465/">juillet 2007</a> mais il a été en butte à de nombreuses critiques et ses développeurs ont du le modifier profondément avant que Jens Axboe, mainteneur de la couche bloc, n'accepte finalement le patch.
<br />
Comme plusieurs distributions incluaient déjà ce patch dans leur noyau, cette entrée dans la branche principale est bienvenue et va permettre de réduire leur charge de maintenance des patchs externes.
<br />
Les utilisateurs de Linux pourront eux profiter de ce système fort utile pour réduire le coût des systèmes de haute disponibilité. Avec DRBD il devient possible de se passer des coûteuses machines spécialisées <a href="http://fr.wikipedia.org/wiki/R%C3%A9seau_de_stockage_SAN">SAN</a> et d'utiliser de simples serveurs Linux reliés entre eux par l'intermédiaire de ce système de stockage distribué.
<br />
<br />
<h3><a name="cookie"></a>Transaction TCP par cookie</h3>
<br />
La pile réseau du noyau 2.6.33 accueille les patchs initiaux du mécanisme de "<a href="http://lwn.net/Articles/366986/">transaction TCP par cookie</a>" qui va permettre, quand l'implémentation sera complète, de résoudre deux problèmes réseau d'un seul coup.
<br />
<br />
En premier lieu la technique de "<a href="http://en.wikipedia.org/wiki/TCP_Cookie_Transactions">transaction TCP par cookie</a>" (TCPCT pour "TCP cookie transactions protocol" en anglais) est une amélioration du mécanisme classique <a href="http://en.wikipedia.org/wiki/SYNcookie">SYN cookies</a> qui est en place depuis plusieurs années et qui permet d'éviter les <a href="http://fr.wikipedia.org/wiki/SYN_flood">attaques par flots de SYN</a> (SYN flood attacks).
<br />
En gros l'attaque se déroule comme ceci : Le client envoie un message SYN au serveur (un message de SYNchronisation pour ouvrir une connexion) et le serveur répond par un SYN-ACK (la SYNchronisation plus l'accusé de réception ACKnowledgement). L'ennui c'est qu'après ça le client malicieux se garde bien de finir la troisième phase de la poignée de main en trois temps (Three-way handshake) et que le serveur reste le bec dans l'eau avec sa connexion ouverte jusqu'à la fin de sa durée d'activité (timeout). Si le client envoie un grand nombre de demandes de connexions qui restent incomplètes alors le serveur finit par être la victime d'un déni de service puisque toutes ses connexions sont ouvertes et attendent des réponses qui ne viendront jamais.
<br />
<a href="http://en.wikipedia.org/wiki/Daniel_J._Bernstein">Daniel J. Bernstein</a> a inventé le mécanisme "SYN cookies" pour contrer ce genre d'attaques. En résumé, après le SYN initial du client le serveur va lui renvoyer un SYN-ACK modifié et contenant un numéro de séquence haché par une clé secrète, un "cookie", et il va tout de suite fermer la connexion. Le serveur économise ainsi ses ressources et n'est plus susceptible d'être victime du déni de service. Quand le client répond par le ACK final, la troisième phase de la poignée de main, le serveur est capable de reconnaitre le client car il se base sur le numéro de séquence.
<br />
SYN cookies est une solution "bricolée" (un hack) mais ça fonctionne assez bien pour bloquer les attaques par flots de SYN. L'inconvénient de cette technique est qu'il devient impossible d'utiliser <a href="http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Selective_acknowledgments">certaines options bien utiles</a> du protocole TCP. De plus la sécurité du cookie est relativement faible et des techniques astucieuses permettent de leurrer le serveur.
<br />
La solution qui est apportée par la nouvelle technique de "transaction TCP par cookie" est simple. Le client va envoyer lui aussi, et ce dès l'étape initiale du SYN, un cookie signé cryptographiquement en direction du serveur. Le serveur se sert de ce cookie-client pour générer un cookie-serveur et le renvoyer au client avec son SYN-ACK. Il coupe ensuite la connexion et n'attends pas de réponse en dépensant des ressources pour rien. Le client renvoie alors le ACK final avec le cookie-serveur qui contient toutes les informations permettant au serveur de connecter le client comme si une poignée de main en trois temps normale avait eu lieu.
<br />
Cette solution élégante est bien plus sécurisée que SYN cookies et elle reste compatible avec les options du protocole TCP.
<br />
<br />
Le second avantage de cette nouvelle fonction de "transaction TCP par cookie" est qu'elle permet d'améliorer la mise en œuvre de <a href="http://fr.wikipedia.org/wiki/DNSSEC">DNSSEC</a> (Domain Name System Security Extensions). Ce mécanisme de sécurisation du protocole <a href="http://fr.wikipedia.org/wiki/Domain_Name_System">DNS</a> (qui fait la correspondance entre une adresse IP et un nom de domaine) a été conçu pour protéger de bout en bout les données échangées par DNS. L'ennui c'est que DNSSEC, outre sa grande complexité, impose de renvoyer des gros paquets. Ces paquets sont trop gros pour le protocole de transmission UDP qui est normalement utilisé par DNS. La taille d'un paquet UDP est de 512 octets alors qu'en moyenne DNSSEC exige 1749 octets. On peut bien entendu fragmenter les échanges en multiples paquets UDP mais cela pose de nombreux problèmes avec les pare-feu et les NAT. On peut alors basculer vers la solution de secours qui consiste à utiliser TCP à la place d'UDP… mais la charge de la machine augmente énormément puisqu'on répète sous TCP une requête qui n'a pas abouti sous UDP et qui a généré un timeout.
<br />
Comment faire ? La réponse est simple puisque le mécanisme "transaction TCP par cookie" permet d'encoder des informations dans les cookies-client et cookies-serveur ! Le mécanisme de "transaction TCP par cookie" se sert de cet espace pour permettre au client d'envoyer une requête DNS dans la première partie de la poignée de main et pour permettre au serveur de renvoyer la réponse. Plus besoin de fragmenter des paquets UDP ou d'attendre les interminables timeouts de bascule vers TCP puisque tout se fait directement dans TCP par l'intermédiaire des cookies.
<br />
<br />
L'article "<a href="http://www.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf">improving TCP security with robust cookies</a>" (au format PDF) permet d'approfondir le sujet et de mieux comprendre les avantages et les inconvénients de cette solution.
<br />
Et oui comme dans toute solution technique il y a des inconvénients. Le principal problème est que SYN cookies (la solution de Bernstein) ne nécessitait qu'une adaptation côté serveur alors que TCPCT impose aussi une mise à jour de tous les clients. Si on ajoute le temps que va prendre l'implémentation complète du protocole dans Linux (le 2.6.33 n'accueille que les patchs initiaux), le temps de déploiement dans toutes les distributions de ces noyaux complètement compatibles et enfin le temps de mise à jour des clients eux-mêmes, on peut penser que le déploiement généralisé est encore assez loin.
<br />
<br />
<h3><a name="ramzswap"></a>Compactage mémoire ramzswap</h3>
<br />
Une <a href="http://lwn.net/Articles/334649/">fonction de compactage de la mémoire</a> nommée ramzswap (anciennement compcache) est entrée dans la partie -staging du noyau 2.6.33.
<br />
L'idée derrière <a href="http://code.google.com/p/compcache/">compcache/ramzswap</a> est de permettre aux LiveCD ou aux petites configurations (netbooks, vieux ordinateurs, clients légers, systèmes embarqués) d'avoir une capacité mémoire artificiellement augmentée grâce à la compression d'une partie des pages mémoires.
<br />
Pour cela un périphérique virtuel en mode bloc est créé à l'amorçage et ce périphérique va jouer le rôle d'une zone de swap dans laquelle les pages mémoire non utilisées depuis un certain temps vont être compressées et stockées.
<br />
Techniquement ramzswap utilise l'algorithme de compression <a href="http://en.wikipedia.org/wiki/Lzo">LZO</a> (par l'intermédiaire des modules noyaux lzo_compress et lzo_decompress) ainsi qu'un allocateur mémoire spécifique (<a href="http://code.google.com/p/compcache/wiki/xvMalloc">xvmalloc</a>). Cet allocateur est nécessaire car les développeurs ont découvert que ceux qui sont déjà disponibles dans le noyau Linux ne remplissaient pas leur cahier des charges très spécial. SLOB a une complexité linéaire, soit O(n), alors que xvmalloc n'a qu'une complexité constante en O(1). SLUB de son côté a une tendance à la fragmentation mémoire que xvmalloc permet d'éviter.
<br />
<br />
Pour utiliser cette fonction de compression de la RAM il suffit (outre les modprobe de chargement des modules) d'une initialisation avec un <i>rzscontrol /dev/ramzswap0 --init</i> suivie d'une activation avec <i>swapon /dev/ramzswap0</i>. Par défaut 15% de la mémoire sera utilisée pour stocker les pages mémoire compressées mais on peut changer ça avec l'option <i>memlimit_kb</i>.
<br />
Pour des raisons de performances et de montée en charge il est préconisé de créer autant de ramswap qu'il y a de cœurs de calcul sur la machine.
<br />
Ainsi si je veux un ramzswap de 256 Mo sur mon laptop bi-cœur je vais faire dans l'ordre :
<br />
<i>modprobe ramzswap num_devices=2</i>
<br />
puis
<br />
<i>rzscontrol /dev/ramzswap0 --init --disksize_kb=131072
<br />
rzscontrol /dev/ramzswap1 --init --disksize_kb=131072</i>
<br />
et enfin
<br />
<i>swapon /dev/ramzswap0
<br />
swapon /dev/ramzswap1</i>
<br />
<br />
Bien entendu toutes ces actions seront la plupart du temps exécutés par des scripts sur nos distributions/LiveCD et l'utilisateur de ramzswap n'aura vraisemblablement pas à se plonger souvent dans <a href="http://compcache.googlecode.com/hg/sub-projects/rzscontrol/man/rzscontrol.html">la page du manuel</a>.
<br />
<br />
D'après les test de performances la fonction ramzswap est très efficace et elle permet vraiment d'être "à l'aise" dans des tailles mémoires non démesurées. Par exemple <a href="http://code.google.com/p/compcache/wiki/Performance">page dédiée</a> du site de compcache donne les résultats de plusieurs expérimentations et le niveau de performance auquel on peut s'attendre lors de l'utilisation (L'expérience a montré que le taux moyen de compression était de 4 pour 1). Un client léger sous <a href="http://fr.wikipedia.org/wiki/Linux_Terminal_Server_Project">LTSP</a> et ayant peu de mémoire peut ainsi utiliser kpdf pour ouvrir simultanément 11 fichiers PDF au lieu de 2 et peut utiliser Firefox pour ouvrir 15 pages webs au lieu de 6.
<br />
<br />
L'implémentation de ramzswap qui se trouve dans le noyau 2.6.33 est considérée pour l'instant comme préliminaire. Tout d'abord elle se trouve dans la partie -staging qui accueille le code non finalisé et surtout les développeurs projettent d'ajouter plusieurs fonctions avant de considérer que l'outil est vraiment complet. On peut donc à brève échéance s'attendre à voir apparaître un meilleur algorithme de défragmentation de la mémoire, une compression des pages de cache et une possibilité de redimensionnement adaptatif du swap de la mémoire.
<br />
<br />
<h3><a name="iobloc"></a>Contrôleur IO-Block</h3>
<br />
Le noyau 2.6.33 accueille dans cette version un <a href="http://lwn.net/Articles/360958/">contrôleur des entrées/sorties en mode bloc</a>.
<br />
Depuis un certain temps plusieurs groupes concurrents avaient commencé à travailler sur ce contrôleur dont le rôle est de faire un arbitrage entre les divers groupes de processus pour accéder aux précieuses ressources d'entrées/sorties. Grâce à ce contrôleur plus de risque qu'un groupe de processus ne monopolise le disque dur et n'affame ses petits camarades.
<br />
L'ennui c'est que les équipes de développeurs concurrents n'arrivaient pas à se mettre d'accord sur l'architecture globale qu'il fallait utiliser dans Linux. Comme l'explique très bien <a href="http://lwn.net/Articles/332839/">cet article LWN</a>, il y avait trois concurrents pour entrer dans la branche principale : dm-ioband, io-throttle et io-controller.
<br />
Le premier, comme son nom le laisse supposer, s'appuie sur le mécanisme du <a href="http://en.wikipedia.org/wiki/Device_mapper">device mapper</a> (une couche d'indirection entre les périphériques blocs qui permet par exemple de faire du RAID logiciel ou du chiffrement de disques). Le second est un mécanisme qui s'implante à plus haut niveau que le device mapper mais qui est aussi plus invasif. Enfin le dernier candidat, io-controller, a choisi de s'interfacer directement dans l'ordonnanceur des entrées/sorties.
<br />
Après plusieurs mois de chamailleries sans issue entre les trois groupes il fallait bien désigner un vainqueur… mais comment faire ?
<br />
Andrew Morton <a href="http://thread.gmane.org/gmane.linux.kernel.containers/11179">a dit</a> avec humour qu'il songeait à enfermer les développeurs de ces trois solutions dans une chambre verrouillée et à revenir 15 minutes plus tard pour voir qui est le gagnant.
<br />
C'est une solution moins coercitive qui a finalement été choisie puisqu'à l'issue du <a href="http://events.linuxfoundation.org/component/registrationpro/?func=details&did=5">Linux Storage and Filesystem Workshop</a> d'avril dernier les divers développeurs sont enfin tombés d'accord sur une stratégie de couplage avec l'ordonnanceur des entrées/sorties (io-controller remporte donc la mise) et lors du <a href="http://sourceforge.net/apps/trac/ioband/wiki/iosummit">dernier mini-sommet</a> d'octobre à Tokyo une <a href="http://sourceforge.net/apps/trac/ioband/raw-attachment/wiki/iosummit/io-controller-mini-summit-2009.pdf">stratégie globale</a> en deux temps a été décidée.
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel/909306">Comme l'écrit Vivek Goyal</a> :
<br />
« <i>Le contrôle des entrées/sorties est un problème complexe et si nous essayons de tout résoudre d'un seul coup en un patch cela devient ingérable et rien n'est accepté dans le noyau. Donc lors du dernier mini-sommet nous nous sommes mis d'accord pour y aller par étape et une fois que le premier bout de code sera dans le noyau et bien stabilisé nous nous occuperons des étapes suivantes</i> »
<br />
<br />
La première étape, celle qui concerne le noyau 2.6.33, voit donc l'inclusion d'un mécanisme de contrôle des entrées/sorties sur les groupes de processus à l'intérieur même de <a href="http://fr.wikipedia.org/wiki/CFQ">CFQ</a> (l'ordonnanceur I/O par défaut de Linux). Ce nouveau mécanisme utilise bien entendu l'infrastructure cgroup qui a été introduite dans le <a href="http://linuxfr.org//2008/01/25/23529.html">noyau 2.6.24</a>. Le nouveau cgroup se nomme "blkio" et il permet d'attribuer un poids au différents groupe de processus (avec une valeur comprise entre 100 et 1000).
<br />
La <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72f924f62a6eb375c7c237ecc911f95be0531d1a">documentation</a> indique comment se servir facilement de cette fonction.
<br />
On commence par créer deux groupes : <i>mkdir -p /cgroup/test1/ /cgroup/test2</i>
<br />
<br />
Et ensuite on fixe les poids respectifs :
<br />
<i>echo 1000 > /cgroup/test1/blkio.weight
<br />
echo 500 > /cgroup/test2/blkio.weight</i>
<br />
<br />
Le groupe test1 aura alors deux fois plus de ressources d'entrées/sorties que le groupe test2.
<br />
<br />
La seconde étape, concernant le contrôleur des entrées/sorties en mode bloc, sera implémentée dans les versions suivantes du noyau Linux. Afin de prendre des décisions d'allocation ayant une visibilité complète de la hiérarchie de stockage (Topology-aware scheduling) il est nécessaire d'inclure des composants à un plus haut niveau que celui de l'ordonnanceur CFS.
<br />
De même, les entrées/sorties asynchrones (buffered writes) ne sont pas gérées par le mécanisme actuel du noyau 2.6.33 et les développeurs s'en occuperont <a href="http://article.gmane.org/gmane.linux.kernel/909306">par la suite</a>:
<br />
« <i>Les entrées/sorties asynchrones c'est un gros bordel et cela réclame des changements dans plein d'endroits pour résoudre le problème. Comme le patch devient trop gros nous ne supportons que le contrôle des I/O synchrones pour le moment</i> ».
<br />
<br />
Même si la solution de contrôle n'est pas encore complète et s'il reste du travail à faire, on peut constater que le noyau Linux avance dans la bonne direction. Les sommets divers qui sont organisés chaque année permettent vraiment aux développeurs de se parler et d'élaborer des compromis afin de développer des solutions techniques aux problèmes. Quant aux administrateurs, ils ont maintenant la possibilité de gérer finement les allocations de ressources entrées/sorties entre les différents groupes de processus.
<br />
<br />
<h3><a name="android"></a>Les pilotes Android retirés du noyau</h3>
<br />
Comme évoqué dans <a href="http://linuxfr.org/~patrick_g/29337.html">ce journal</a> les pilotes Android ont été <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b0a0ccfad85b3657fe999805df65f5cfe634ab8a">retirés</a> par Greg Kroah-Hartman de la branche -staging du noyau 2.6.33. De nombreux commentaires intéressants à ce sujet peuvent être lus sur <a href="http://lwn.net/Articles/372419/#Comments">cet article du site Linux Weekly News</a>. On a ainsi <a href="http://en.wikipedia.org/wiki/Chris_DiBona">Chris DiBona</a>, <i>Engineering Manager Open Source</i> à Google, qui <a href="http://lwn.net/Articles/372568/">affirme</a>: « <i>la réalité c'est que la branche principale ne veut pas notre code donc un fork est la réponse normale à cet état de fait</i> ». Greg KH a immédiatement répliqué : « <i>Ce n'est pas vrai. Nous ne voulons pas du code <span>tel qu'il est</span> mais c'est juste parce qu'il nécessite un gros travail. Ce n'est pas différent pour toutes les autres contributions au noyau</i> ».
<br />
<br />
La discussion a été quelque peu acrimonieuse mais elle a également permis de lire plusieurs avis techniques. Apparemment c'est l'ajout de "wakelock" qui est apparu aux yeux de beaucoup de kernel hackers comme le point le plus problématique du code d'Android.
<br />
<a href="http://lwn.net/Articles/318611/">Wakelock</a> est une fonction spécifique du noyau utilisé dans Android et qui permet d'empêcher le système d'entrer en phase économie d'énergie. Cela semble contre-intuitif de procéder ainsi mais la philosophie des ingénieurs de Google est que par défaut le système devrait <span>toujours</span> être dans cet état d'économie d'énergie. Si une application a besoin d'utiliser des cycles du processeur alors elle doit poser <span>explicitement</span> un verrou wakelock interdisant la mise en veille pour que le travail soit effectué. Sinon le système restera endormi par défaut.
<br />
En envoyant la commande WAKE_LOCK_SUSPEND le système ne pourra plus entrer en veille tandis que WAKE_LOCK_IDLE empêche le processeur d'entrer dans un mode à faible consommation. Tout ce mécanisme interne au noyau patché d'Android est accessible aux applications qui peuvent placer leurs verrous et les enlever par l'intermédiaire de /sys/power/wake_lock et /sys/power/wake_unlock.
<br />
Les développeurs du noyau Linux considèrent cependant que wakelock est un très vilain hack pour plusieurs raisons. Tout d'abord ce mécanisme est en grande partie redondant avec l'API <a href="http://www.celinux.org/elc08_presentations/elc2008_pm_qos_slides.pdf">pm_qos</a> (Power Management Quality of Service) qui existe déjà dans le noyau. Si Android a besoin de choses très spécifiques alors le travail aurait du consister en l'ajout de fonctions à pm_qos et pas au développement d'une solution différente.
<br />
Autre problème : La <a href="http://www.mjmwired.net/kernel/Documentation/power/states.txt">gestion de l'énergie</a> traditionnelle sous Linux qui se base sur des écritures de commandes dans /sys/power/state est désactivée par le patch wakelock d'Android car la compatibilité n'est pas prévue.
<br />
Les développeurs de Linux relèvent également que le code de wakelock est inutilement compliqué avec plusieurs possibilités différentes alors qu'en réalité tout cela pourrait en définitive se ramener à un simple indicateur pour empêcher la mise en veille.
<br />
Enfin si une application utilisateur se crashe au mauvais moment alors qu'elle détient un wakelock... dommage pour vous mais le système ne passera plus en veille !
<br />
<br />
Il faudra donc que Google réponde à toutes ces critiques techniques et arrive à convaincre les développeurs de la pertinence de sa solution si le géant américain désire vraiment intégrer son code dans la branche principale. <a href="http://lwn.net/Articles/372568/">Selon Chris DiBona</a> il faut que les développeurs de Linux acceptent le code tel qu'il est car les besoins d'un système pour smartphone sont très différents des autres et nécessitent des solutions particulières : « <i>Android n'est pas la même chose qu'un serveur relié à Internet et penser que Linux sur un mobile est la même chose que Linux sur un serveur explique pourquoi, avant qu'Android n'arrive, Linux sur les mobiles ne rencontrait presque aucun succès</i> ».
<br />
<br />
Il lui a été immédiatement répondu que, même si le monde des systèmes d'exploitation pour téléphones est sans doute particulier avec des besoins spécifiques, on ne peut que constater que jusqu'à présent le noyau Linux a réussi à répondre aux besoins d'une très large gamme de machines (du gigantesque supercalculateur au minuscule ordinateur embarqué). La synergie permise par un développement unifié autour d'un seul noyau modulaire est une force redoutable et Google, avec son fork, refuse de jouer le jeu de ce développement unifié et choisit la fragmentation. Il est vrai que pour participer à ce jeu la barre est assez haute puisqu'il faut écouter les avis d'autres développeurs hautement expérimentés et accepter de modifier plusieurs fois son code afin de répondre à leurs critiques.
<br />
L'ennui c'est que ce retour de la communauté Linux n'a pu être pris en compte par Google qui a choisi de créer Android en secret. Les patchs concernant wakelock ont été postés sur la LKML seulement <a href="http://thread.gmane.org/gmane.linux.power-management.general/12803">en février 2009</a> alors qu'Android était en développement depuis au moins l'année 2005 et le <a href="http://fr.wikipedia.org/wiki/SDK">kit de développement</a> des applications disponible <a href="http://en.wikipedia.org/wiki/Android_%28operating_system%29#Software_development_kit">depuis novembre 2007</a>.
<br />
Google a vraiment jeté son paquet de code "par dessus le mur" comme disent les anglo-saxons (<i>dumping code over the wall</i>) sans aucune volonté de l'adapter aux exigences des mainteneurs de Linux.
<br />
<br />
Matthew Garrett a <a href="http://lwn.net/Articles/372631/">répliqué</a> à Chris DiBona que le code d'Android pouvait être accepté si Google voulait bien faire l'effort d'écouter les remarques des développeurs du noyau : « <i>Si le monde entier vous suggère de faire un truc de façon différente et que vous refusez alors cela ne constitue pas un effort honnête de travail en commun. Nokia a réussi à obtenir le même niveau d'économie d'énergie sans tous ces changements invasifs donc toute affirmation selon laquelle wakelock serait absolument nécessaire pour qu'Android atteigne ses objectifs est sans fondement</i> ».
<br />
L'attitude des développeurs de Google ayant consisté à développer ce code secrètement et à refuser d'écouter les critiques techniques des autres développeurs a été jugé arrogante par plusieurs personnes. Le message résumant le mieux ce sentiment est celui de <a href="http://lwn.net/Articles/372969/">rahvin</a> : « <i>Je suis content que les développeurs Google aient participé à cette discussion. Ils m'ont appris quelque chose que je ne savais pas : Que Google et ses développeurs croient qu'ils ont raison quoi que pensent les autres. C'est peut-être un problème de culture d'entreprise. Ils croient vraiment qu'ils ont raison et que tous les autres ont tort.
<br />
Je pense que n'importe qui serait d'accord pour dire que parfois c'est mieux d'être en dehors de la branche principale mais c'est l'exception et pas la règle. Pour entrer dans la branche principale, il faut écouter les autres développeurs quand ils vous disent que votre code est une saleté, que votre solution est mauvaise et qu'il en existe une meilleure. C'est d'autant plus vrai quand ce sont tous les développeurs travaillant dans le même domaine (ici l'embarqué) qui vous disent que votre approche est mauvaise.
<br />
Pour moi c'est une révélation de constater à quel point les développeurs de Google sont arrogants au sujet de leur code</i> ».
<br />
<br />
Cet avis est sans doute exagérément critique puisqu'il semble y avoir de la bonne volonté du côté des développeurs de Google pour collaborer plus avant avec la branche principale. Brian Swetland, ingénieur à Google, a ainsi <a href="http://lwn.net/Articles/373441/">expliqué</a>: « <i>J'aimerai bien discuter de tout ça dans un forum où le but est de résoudre des problèmes communs plutôt que de blâmer les gens. Nous savons que pas mal de gens auraient été plus contents si nous avions résolu tout ça avant que nous ne sortions notre version 1.0... mais ça ne s'est pas passé comme ça et argumenter à ce sujet n'apporte rien à personne. Comprendre comment collaborer afin que les problèmes futurs puissent être résolus plus tôt me semble en revanche bien plus productif.
<br />
Donc quand et où pouvons-nous nous rencontrer avec les autres développeurs qui s'occupent de la gestion de l'énergie sous Linux afin de parler de tout ça ?</i> ».
<br />
<br />
On voit donc qu'il y a une chance que Google fasse l'effort d'adapter son code et le prochain rendez-vous est planifié pour le sommet "Power Management" du mois d'août à Boston.
<br />
La morale de l'histoire - comme toujours - est qu'il faut poster son code "tôt et souvent" afin d'obtenir un retour de la communauté, qu'il faut penser à intégrer la branche principale dès le début, avant même de sortir son produit, pour éviter d'être bloqué par la suite en cas de changement du code. Enfin, et comme le rappelle Jonathan Corbet, « <i>les développeurs du noyau doivent travailler pour tout le monde alors que les développeurs de l'embarqué résolvent des problèmes spécifiques sous une forte contrainte de délai. Souvent ils ne pensent pas à étendre un mécanisme pré-existant qui pourrait répondre à leur besoin. Au lieu de ça ils bricolent en vitesse un truc bancal qui n'est pas soumis à un passage en revue par les développeurs de la branche principale. On pourrait penser que Google a le temps, les ressources et la connaissance du développement noyau qui lui permettraient d'éviter tous ces problèmes et faire les choses proprement. Au lieu de ça nous avons là un exemple classique de la façon dont les choses peuvent mal tourner</i> ».
<br />
<br />
<h3><a name="nouveau"></a>Intégration de Nouveau</h3>
<br />
Au début de la période de merge du 2.6.33 quand Dave Airlie, responsable de la partie graphique du noyau (Direct Rendering Manager), a proposé à Linus de fusionner sa branche de développement il ne s'attendait certainement pas au message cinglant qu'il allait recevoir en retour.
<br />
Pourtant <a href="http://thread.gmane.org/gmane.linux.kernel/925186">sa demande de récupération du code</a> ("pull" dans le langage du gestionnaire de versions git) était tout à fait banale. Durant les quinze jours de la "fenêtre de tir" chaque gardien d'une sous-partie du noyau indique ainsi à Linus quelles sont les nouveautés qui sont incluses dans la branche et lui demande de faire un pull de sa branche... mais là Linus a eu le sentiment d'être volé sur la marchandise puisque le pilote libre Nouveau, destiné à faire fonctionner les cartes graphiques NVidia, n'était pas dans le paquet cadeau !
<br />
Selon le message de commit de Dave Airlie le plus gros manque de sa branche était la gestion de l'énergie du pilote Radeon ce qui lui a valu <a href="http://thread.gmane.org/gmane.linux.kernel/925370">cette réplique immédiate</a>:
<br />
« <i>Non, le plus gros manque c'est que Fedora continue d'inclure Nouveau et que je ne vois toujours pas les gens de Red Hat essayer de l'inclure dans la branche principale. Bordel, qu'est-ce qu'il se passe ?</i> ».
<br />
Certains développeurs ont essayé d'expliquer que le pilote n'était pas encore vraiment mûr... mais Linus sait être <a href="http://article.gmane.org/gmane.linux.kernel/925388">brutalement franc</a> dans ses échanges :
<br />
«<i>J'ai déjà entendu toutes ces excuses. Si ce n'est pas encore prêt alors ils ne devraient pas le proposer à des millions de personnes. Et si c'est prêt alors ils devraient travailler pour l'inclure. Pas d'excuse</i> ».
<br />
<a href="http://article.gmane.org/gmane.linux.kernel/925458">Suivi de</a>:
<br />
« <i>Quand j'ai soulevé ce point lors du dernier sommet du noyau j'ai entendu plein d'excuses différentes. L'une d'elle était que cela ne faisait pas partie d'une version officielle de Fedora (ce qui n'est certainement pas vrai au moins pour Fedora 12).
<br />
J'ai aussi entendu l'excuse "Oh mais c'est difficile à inclure" mais je sais que c'est de la connerie parce que je regarde la branche git de Fedora et je vois ça merge sans aucun conflit.
<br />
L'excuse la plus commune est "Oh mais le code va encore changer". Pour commencer ce n'est même pas une bonne excuse mais de toute façon la branche -staging est justement là pour ça.
<br />
Quelqu'un a même fait un commentaire grotesque disant que "Fedora n'est pas une vraie distribution, donc elle n'est pas obligée de suivre les règles que tout le monde a accepté de suivre il y a des années, c'est-à-dire d'inclure les trucs dans la branche principale".
<br />
Je <b>pense</b> que cette dernière excuse est une blague. Mais c'est vraiment difficile d'être affirmatif, car les autres excuses sont tout autant débiles. Les gens semblent vraiment sortir n'importe quelle excuse merdeuse pour justifier un truc que tout le monde sait être complètement faux</i> ».
<br />
<br />
Devant ce tir de barrage les développeurs du pilote Nouveau ont dû céder et Dave Airlie a <a href="http://article.gmane.org/gmane.linux.kernel/925943">promptement annoncé</a> que la branche "Le poney Nouveau pour Noël" était disponible pour merge dans le 2.6.33. Le "poney" du titre de cette branche vient de l'expression anglo-saxonne "Can I have a pony too?" qu'on utilise traditionnellement pour réclamer humoristiquement une chose extraordinaire en plus de tout ce qu'on vient déjà d'avoir. C'est un peu l'équivalent de "Je peux avoir aussi cent balles et un mars ?".
<br />
Bien entendu Linus <a href="http://article.gmane.org/gmane.linux.kernel/926222">a été content</a> d'avoir obtenu ce qu'il voulait ("PONEYS ! Super ! J'adoooore les poneys !") et les utilisateurs du noyau 2.6.33 pourront profiter d'un pilote libre pour leurs cartes NVidia qui sera de meilleure qualité que le très limité et incompréhensible pilote nv (rendu sciemment illisible par les développeurs de NVidia qui utilisent la technique de <a href="http://fr.wikipedia.org/wiki/Code_imp%C3%A9n%C3%A9trable">l'obfuscation</a>).
<br />
Le blob binaire qui est nécessaire pour faire fonctionner Nouveau (le micrologiciel ctxprogs) a même été réécrit par ingéniérie inverse et une version libre, compatible avec les cartes GeForce 6 et 7, a été <a href="http://thread.gmane.org/gmane.comp.freedesktop.xorg.nouveau/4211">rendue disponible</a>.
<br />
Le support de double écran est possible via <a href="http://en.wikipedia.org/wiki/RandR">RandR</a> et Nouveau propose aussi l'accélération par l'intermédiaire de <a href="http://en.wikipedia.org/wiki/Xvideo">Xvideo</a>. Bien entendu le support de la 3D n'est pas encore vraiment au top car c'est une tâche très complexe mais nul doute doute que le support va s'améliorer. Une <a href="http://nouveau.freedesktop.org/wiki/FeatureMatrix">matrice de compatibilité</a> est disponible sur le site du projet.
<br />
Nouveau, fondé par le français <a href="http://people.freedesktop.org/~marcheu/">Stéphane Marchesin</a>, continue d'avancer à bon rythme et comme c'était prévu le code bouge beaucoup. Ainsi la partie en espace utilisateur de Nouveau <a href="http://www.phoronix.com/scan.php?page=news_item&px=Nzk4Nw">a rompu la compatibilité</a> avec le pilote DRM (Direct Rendering Manager) intégrée dans le noyau. De plus, juste après l'intégration dans la branche -staging, tout le code a été nettoyé, plus de 15000 lignes ont été supprimées, car il a été décidé que le pilote dépendrait désormais exclusivement de KMS (Kernel Mode Setting). Si votre noyau n'inclut pas KMS et que vous voulez profiter de Nouveau il va falloir songer à mettre à jour !
<br />
<br />
<h2><a name="en_bref"></a>En bref (<a href="#sommaire">↑</a>)</h2>
<br />
<ul><li><a name="radeon"></a>Avec le pilote Nouveau qui entre dans la branche -staging on peut noter que le pilote Radeon, lui, quitte cette antichambre. Il est maintenant considéré comme suffisamment stable et avancé pour rejoindre la partie "normale" du noyau. Dans cette version 2.6.33 on trouve le support du <a href="http://fr.wikipedia.org/wiki/DisplayPort">DisplayPort</a> et de l'Embedded DisplayPort, la gestion des interruptions pour les cartes de type r6xx/r7xx ainsi qu'un support basique de la norme <a href="http://fr.wikipedia.org/wiki/HDMI">HDMI</a> pour les R600. Même si le pilote Radeon est encore en retard sur les toutes dernières générations de cartes on peut considérer que la sortie de la branche -staging est le signe de la maturité. Comme l'écrit Dave Airlie : « <i>Les distributions peuvent maintenant songer à l'activer</i> ».
<br />
</li>
<br />
<li><a name="devicemapper"></a>La couche du <a href="http://en.wikipedia.org/wiki/Device_mapper">device-mapper</a>, qui est une interface virtuelle servant à faire communiquer entre eux des périphériques blocs, vient de gagner dans cette version du noyau la capacité de restaurer des instantanés du système de fichiers (snapshots). La fonction de prise de snapshot existait depuis déjà quelque temps mais elle n'autorisait pas une restauration dans le même périphérique que celui à l'origine de snapshot.
<br />
Cette nouvelle fonction de restauration va permettre des choses fort utiles pour les systèmes qui utilisent le device-mapper, c'est-à-dire essentiellement les gens qui utilisent le <a href="http://fr.wikipedia.org/wiki/LVM">gestionnaire de volumes logiques</a> LVM. On pourra ainsi prendre un snapshot juste avant une mise à jour du système (via Aptitude ou Yum ou tout autre moyen) et faire un retour arrière en cas de problème... et ce quel que soit le système de fichiers utilisé puisque c'est la couche device-mapper qui s'occupe de tout !
<br />
</li>
<br />
<li><a name="better-io"></a>Les processus générant des entrées/sorties sous forme de petits batchs périodiques vont voir leurs performances s'améliorer. En effet le noyau 2.6.33, grâce au travail de Nathan Roberts et de Jeff Moyer, va maintenant accumuler intelligemment ces entrées/sorties asynchrones avant de les envoyer en une seule fois à la couche en mode bloc. Selon <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb1e33eed48165763edc7a4a067cf5f74898d0b">le message de commit</a> les performances d'un processus qui fait des batchs de 16 lectures séquentielles de 4 Ko de données sont améliorées de 30%.
<br />
</li>
<br />
<li><a name="anticipatory"></a>Les quatre <a href="http://fr.wikipedia.org/wiki/Ordonnancement_d%27E/S">ordonnanceurs des entrées/sorties</a> du noyau Linux ne sont plus que trois dans cette version 2.6.33. L'ordonnanceur "<a href="http://fr.wikipedia.org/wiki/Anticipatory_scheduling">Anticipatory</a>" a été retiré du code car il n'apporte aucun avantage particulier par rapport à CFQ ("<a href="http://fr.wikipedia.org/wiki/Completely_Fair_Queuing">Completely Fair Queuing</a>" Scheduler) et qu'il est toujours bon de nettoyer du code qui ne sert plus. C'est donc la fin du chemin pour "Anticipatory" qui avait été introduit dans le noyau 2.5.59-mm5 et qui a été l'ordonnanceur par défaut entre le 2.6.0 et le 2.6.18 avant d'être remplacé dans ce rôle par CFQ. Sic transit gloria mundi.
<br />
Face à CFQ il ne reste donc plus que l'ordonnanceur "<a href="http://fr.wikipedia.org/wiki/Noop_scheduler">NOOP</a>" (NO OPeration) qui comme son nom l'indique ne fait rien par lui même et s'en remet aux couches supérieures et l'ordonnanceur "<a href="http://fr.wikipedia.org/wiki/Deadline_scheduler">Deadline</a>" qui est spécialement recommandé pour les bases de données.
<br />
Jens Axboe indique dans son message de commit que le travail d'élimination de code sera sans doute poursuivi dans le futur : « <i>Il faut espérer qu'à un moment nous pourrons revenir à un seul ordonnanceur des entrées/sorties. Au moins ça (l'élimination d'Anticipatory) nous rapproche de ce but d'avoir un seul ordonnanceur intelligent</i> ».
<br />
</li>
<br />
<li><a name="reiserfs"></a>Le système de fichiers Reiserfs est maintenant <a href="http://lkml.indiana.edu/hypermail/linux/kernel/0912.0/03048.html">officiellement</a> déclaré libéré de l'infâme <a href="https://linuxfr.org//2008/05/18/24099.html">verrou global du noyau</a> (BKL).
<br />
Le français Frédéric Weisbecker a réussi à éradiquer toutes les occurrences du BKL du code de Reiserfs ce qui représente un bel exploit étant donné que ce système de fichiers en faisait un usage prononcé et peu académique (voir son <a href="https://linuxfr.org//comments/1064931.html#1064931">message explicatif</a> sur LinuxFr à ce sujet). Du côté des performances les choses sont restées plus ou moins égales (on perd d'un côté, on gagne de l'autre) avec le passage aux <a href="http://en.wikipedia.org/wiki/Reentrant_mutex">mutex réentrant</a> à la place du verrou géant.
<br />
</li>
<br />
<li><a name="sysctl"></a>Le code de l'appel système sysctl, permettant de lire ou d'écrire les paramètres système de la machine, <a href="http://lwn.net/Articles/361453/">a été retiré</a> du noyau 2.6.33. C'est le résultat du travail d'Eric Biederman qui a toujours soutenu que l'interface de configuration basée sur la hiérarchie /proc/sys est bien plus facile à utiliser et à scripter. <a href="http://lwn.net/Articles/361001/">Son patch</a> enlève donc plus de 2000 lignes de code et implémente une couche (un wrapper) qui permet aux anciennes applications basées sur sysctl de continuer à fonctionner puisque ces petites naïves ne s'apercevront pas que maintenant c'est en réalité /proc/sys qu'elles utilisent.
<br />
</li>
<br />
<li><a name="tracing"></a>Les infrastructures de traçage ftrace (qui a fait son entrée dans le noyau 2.6.27) et de profilage perf events (ayant fait son apparition dans le 2.6.31 sous le nom de perf counters) ont été grandement améliorées dans cette nouvelle version du noyau.
<br />
On peut maintenant, grâce au travail de Masami Hiramatsu, insérer des points de marquages dynamiques. La nouvelle fonction de traçage dynamique se base sur <a href="http://www.mjmwired.net/kernel/Documentation/kprobes.txt">kprobe</a> et pour ajouter ces points il suffit d'écrire une ligne dans <i>/sys/kernel/debug/tracing/kprobe_events</i>.
<br />
Il est aussi possible d'employer <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1889d20922d14a97b2099fa4d47587217c0ba48b">des expressions régulières</a> pour filtrer les résultats de traçage et un outil de "diff" permet de visualiser facilement les changements de performances entre deux tests successifs.
<br />
Perf events est maintenant compatible avec les architectures <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=58e9f94138c1d9c47f6a63632ca7a78fc6dcc15f">ARM</a>, <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=11ada26c78febe4662a8e848f3bff74e3200c920">ia64</a> et <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcd14b3203b538dca04a2b065c774c0b57863eec">Alpha</a>. On trouve aussi maintenant <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0722db015c246204044299eae3b02d18d3ca4faf">une commande</a> pour enregistrer toutes les allocations mémoires du noyau, pour tracer <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55ffb7a6bd45d0083ffb132381cb46964a4afe01">un processeur particulier</a> parmi les autres, etc. A noter également que l'infrastructure Hardware-breakpoint (qui utilise les registres spéciaux des processeurs pour faciliter le déboguage) a été réimplémentée par dessus perf events comme on peut le voir dans le <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=24f1e32c60c45c89a997c73395b69c8af6f0a84e">joli schéma</a> du commit.
<br />
</li>
<br />
<li><a name="recvmmsg"></a>L'appel système <a href="http://www.linux-france.org/article/man-fr/man2/recv-2.html">recvmsg</a> permet de recevoir un message sur un socket réseau. Comme tous les <a href="http://fr.wikipedia.org/wiki/Appel_syst%C3%A8me">syscall</a> le fait de franchir la séparation entre espace utilisateur et espace noyau signifie qu'il s'agit d'une opération coûteuse. Arnaldo Carvalho de Melo a eu l'idée de créer <a href="http://lwn.net/Articles/334532/">un nouvel appel système</a> qui permettrait de recevoir plusieurs messages d'un seul coup au lieu d'un seul. Astucieusement nommé recvmmsg (le "mm" c'est pour <b>m</b>ultiple <b>m</b>essages) ce syscall est une excellente idée et il permettra de réduire la surcharge (overhead) dans les échanges réseaux à haut débit. Évidemment il faut maintenant que les applications utilisent ce nouvel appel système pour profiter de ses bienfaits.
<br />
</li>
<br />
<li><a name="LSM-hooks"></a>Les modules de sécurité basés sur le chemin (par opposition à SELinux qui fonctionne avec des labels attachés aux objets) vont voir leur travail facilité dans le noyau 2.6.33. De nouveaux hooks (crochets logiciels) ont été ajoutés afin de pouvoir contrôler les commandes <a href="http://fr.wikipedia.org/wiki/Chmod">chmod</a> (permet de changer les permissions), <a href="http://fr.wikipedia.org/wiki/Chown">chown</a> (permet de changer le propriétaire) et <a href="http://fr.wikipedia.org/wiki/Chroot">chroot</a> (changer le répertoire racine d'un processus). Le module de sécurité basé sur le chemin <a href="http://en.wikipedia.org/wiki/TOMOYO_Linux">TOMOYO</a>, qui est entré dans le <a href="http://linuxfr.org//2009/06/10/25555.html">noyau 2.6.30</a>, pourra maintenant contrôler plus finement ces trois commandes.
<br />
</li>
<br />
<li><a name="optimisation"></a>Vous êtes des fondus de l'optimisation ultime ? Vous ne jurez que par Gentoo et vous ne compilez dans votre noyau que les modules strictement indispensables afin de gagner quelques Ko ? Soyez contents car Ted Ts'o a pensé à vous. <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=24b584240a0006ea7436cd35f5e8983eb76f1e6f">Maintenant il est possible</a> de choisir l'option de configuration CONFIG_EXT4_USE_FOR_EXT23 afin de pouvoir utiliser directement le code du système Ext4 pour monter vos systèmes Ext2 et Ext3. Ext4 n'est en effet qu'une profonde modernisation de la série des Ext(x) et son code préserve la compatibilité permettant de monter ses respectables ancêtres.
<br />
L'option CONFIG_EXT4_USE_FOR_EXT23 permet donc de ne plus compiler du tout dans son noyau les anciens systèmes de fichiers Ext2 et Ext3. Comme le dit Ted c'est une option rêvée pour les "minimalist kernel fanatics".
<br />
</li>
<br />
<li><a name="batman"></a>Le protocole de réseau B.A.T.M.A.N (Better Approach To Mobile Adhoc Networking) est un nouveau type de <a href="http://fr.wikipedia.org/wiki/R%C3%A9seau_ad_hoc">réseau ad hoc</a> qui est en cours de développement. Le routage pour ces réseaux dont l'infrastructure n'est pas définie et organisée strictement est un problème difficile à résoudre. Jusqu'à présent c'est surtout le protocole <a href="http://fr.wikipedia.org/wiki/OLSR">OLSR</a> qui était utilisé mais les hackers allemands de la communauté <a href="http://en.wikipedia.org/wiki/Freifunk">Freifunk</a> ont décidé de proposer <a href="http://www.open-mesh.net/wiki/why-starting-batman">une meilleure solution</a>. Conceptuellement l'idée derrière B.A.T.M.A.N peut se comparer à un chemin emprunté par des fourmis laissant des phéromones. Plus il y a de fourmis qui passent et plus la piste odorante en attire d'autres. Ici des paquets OGM (Originator Message) de 52 bits sont envoyés en permanence avec un numéro de séquence. Ces paquets jouent le rôle des phéromones et plus il y a de données qui arrivent d'un lien plus ce lien se voit accordé de "confiance" pour transmettre les nouveaux paquets. C'est ce phénomène d'auto-renforcement et d'auto-organisation qui est au cœur de B.A.T.M.A.N.
<br />
Le noyau Linux 2.6.33 <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5beef3c9bf7f967a4a70ddb0108fd3e459fed133">accueille dans sa branche -staging</a> la version 2 du protocole B.A.T.M.A.N dont le principe, très intéressant, est exposé <a href="http://www.open-mesh.net/wiki/BATMANConcept">sur cette page</a>.
<br />
</li>
<br />
<li><a name="loongson"></a>Le processeur <a href="http://en.wikipedia.org/wiki/Loongson#Loongson_2F">Loongson 2F</a>, basé sur l'architecture <a href="http://en.wikipedia.org/wiki/MIPS_architecture">MIPS</a> est une puce conçue par l'Institute of Computing Technology de l'Académie des sciences chinoise. Le but recherché par les autorités chinoises avec toutes ces versions successives de la famille Loongson est de parvenir à une certaine indépendance par rapport aux processeurs d'origine américaine. Le noyau 2.6.33 propose donc <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6f7a251a259e5bf58a9ff334bdcfa3e42b6cb7a3">la gestion</a> de la dernière version 2F, le code permettant la <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f8ede0f700f5478851f242f291d203cde54ca6cf">variation automatique de fréquence</a> ainsi que la <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f181bf60e3f31cdab48bd8b9d913201ed2f9e522">mise en veille/hibernation</a>. A noter que si, comme Richard Stallman, vous ne voulez utiliser que des logiciels libres (y compris les micrologiciels et le BIOS) alors <a href="http://lemote.com/english/yeeloong9c.html">ce portable Lemote</a> basé sur un Loongson 2F est vraisemblablement ce qu'il vous faut. En tout cas RMS <a href="http://richard.stallman.usesthis.com/">ne jure que par lui</a>.
<br />
</li>
<br />
<li><a name="powerpc"></a>Du côté de l'architecture PowerPC il y a aussi du neuf. Tout d'abord le noyau 2.6.33 ajoute le support dans la branche principale des consoles de jeu Nintendo <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e90d71d0f52fb3d619b96ba92b7614fed7cb819e">Gamecube</a> et Nintendo <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5a7ee3198dfade8eaea260399fd168e4e9c1a3a9">Wii</a> (avec les patchs associés pour le processeur <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=45158dc7d68972de919c24130b784b548df06546">Broadway</a>, la carte graphique <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9c21025c7845bd32fb76eb38cb512c911930d85d">Hollywood</a>, etc.). A l'autre extrémité du spectre de puissance on trouve les patchs améliorant le support des partitions logiques dynamiques (<a href="http://en.wikipedia.org/wiki/DLPAR">DLPAR</a> pour Dynamic Logical Partitioning) sur les gros serveurs PowerPC d'IBM. On peut ainsi <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ab519a011caa5ec47d992cb8a4fc8e7af9b9e3f8">plus facilement</a> ajouter ou enlever "à chaud" des ressources comme des cartes processeurs, des barrettes mémoire ou divers périphériques.
<br />
</li>
<br />
<li><a name="tiny"></a>La technique du <a href="http://en.wikipedia.org/wiki/Read-copy-update">Read-Copy update</a> est utilisée dans Linux afin de synchroniser de multiples threads pour leur permettre de lire simultanément une donnée sans poser dessus un verrou coûteux. C'est un mécanisme très efficace dont le grand spécialiste est Paul McKenney. Dans le noyau 2.6.29 la fonction RCU est devenue "hiérarchique" pour faciliter encore plus la montée en charge sur les machines massivement multi-processeurs.
<br />
Lors de la précédente conférence linux.conf.au un sondage informel a été organisé par Paul McKenney qui a demandé à ses pairs si un code spécialement adapté à l'embarqué serait utile. Comme la réponse <a href="http://paulmck.livejournal.com/2280.html">a été positive</a> le nouveau noyau 2.6.33 introduit un petit cousin du RCU hiérarchique à destination des machines n'ayant qu'un seul processeur (pas compatible SMP donc). Ce "<a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9b1d82fa1611706fa7ee1505f290160a18caf95d">Tiny RCU</a>" permet, sur architecture x86, de gagner environ 2,7 Ko sur le module quand on passe de l'option CONFIG_TREE_RCU à CONFIG_TINY_RCU (3526 octets pour "tree" contre seulement 858 octets pour "tiny").
<br />
Comme il en a pris l'habitude depuis plusieurs mois, Paul McKenney a décrit en détail ses travaux dans <a href="http://lwn.net/Articles/323929/">un article du site LWN</a> (avec des quizzs à la fin pour voir si vous avez suivi ou si, comme moi, vous faites juste semblant de comprendre).
<br />
</li>
<br />
<li><a name="nilfs"></a>Le système de fichiers <a href="http://www.nilfs.org/en/index.html">NILFS</a> (New Implementation of a Log-structured File System) basé sur la technique d'écriture des données "en flux" sous forme de log et qui a fait son entrée dans <a href="http://linuxfr.org//2009/06/10/25555.html">le noyau 2.6.30</a>, a été largement optimisé dans la version 2.6.33. Ryusuke Konishi <a href="http://thread.gmane.org/gmane.linux.kernel/926113">annonce ainsi</a> que l'allocation des blocs bénéficie d'un meilleur temps de latence, que la reprise après un unmount "sauvage" est plus rapide (<a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=050b4142c9f3cb3a213f254bd1a1fa1476800585">plus de 60% de réduction</a> pour le temps de remontage du fichier du fait de l'utilisation de readahead) et enfin que la suppression de fichiers de grande taille est accélérée (18% de mieux).
<br />
</li>
<br />
<li><a name="xfs"></a>Le système de fichiers <a href="http://fr.wikipedia.org/wiki/XFS">XFS</a>, créé à l'origine par la société SGI et réimplémenté dans Linux, avait jusqu'à présent une infrastructure de tracing bien à lui. Dans le noyau 2.6.33 ce code baroque et redondant a été retiré et XFS utilise maintenant l'infrastructure commune de tracing du noyau. L'activation du tracing de XFS se fait avec un simple "<i>echo 1 > /sys/kernel/debug/tracing/events/xfs/enable</i>" et les résultats devraient être de bien meilleure qualité puisque de nombreux nouveaux points de traçage ont été ajoutés pour voir plus finement ce qui se passe lors du fonctionnement du système de fichier. <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0b1b213fcf3a8486ada99a2bab84ab8c6f51b264">Comme le signale</a> Christoph Hellwig, et en dépit des ajouts de nouveaux points de traçage, « <i>Le truc vraiment cool dans ce patch c'est qu'en fait il enlève plein de lignes de code tout en ajoutant des fonctions</i> ».
<br />
</li>
<br />
<li><a name="kvm"></a>La machine virtuelle KVM (<a href="http://fr.wikipedia.org/wiki/Kernel-based_Virtual_Machine">Kernel-based Virtual Machine</a>) a été améliorée dans cette version 2.6.33 du noyau Linux.
<br />
Par exemple KVM utilise depuis toujours les <a href="http://en.wikipedia.org/wiki/Model-specific_register">registres spécifiques</a> (MSR pour Model-specific Registers) des processeurs pour fonctionner. Cette utilisation est maintenant rendue bien plus rapide car, au lieu de charger/décharger en permanence ces registres à chaque <a href="http://fr.wikipedia.org/wiki/Commutation_de_contexte">changement de contexte</a>, le noyau 2.6.33 autorise maintenant un partage des données <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18863bdd60f895f3b3ba16b15e8331aee781e8ec">dans certains cas</a>. Le gain annoncé est très important puisqu'il peut atteindre environ <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=26bb0981b3ff00b9177d61fe55806db978862b3c">2 000 cycles de processeur</a>. Dans son <a href="http://thread.gmane.org/gmane.comp.emulators.kvm.devel/43718">message récapitulatif</a> des patchs incorporés dans cette version, Avi Kivity (qui est développeur principal de KVM) indique également que la machine virtuelle cohabite mieux avec l'infrastructure de changement automatique de fréquence cpufreq et qu'il <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=10474ae8945ce08622fd1f3464e55bd817bf2376">n'est plus nécessaire</a> de décharger d'abord le module KVM avant d'utiliser d'autres solutions de virtualisation.
<br />
</li>
<br />
<li><a name="hyper-v"></a>Le pilote Microsoft hyper-v, destiné à faire fonctionner un système Linux en tant qu'invité (guest) sur un système Windows, avait été en septembre dernier <a href="http://linuxfr.org//~patrick_g/28751.html">sous la menace</a> d'une éjection pure et simple de la branche -staging pour cause d'abandon. Depuis les développeurs Microsoft sont réapparus et le noyau 2.6.33 contient donc toujours ce fameux pilote. En décembre Greg KH <a href="http://www.kroah.com/log/linux/staging-status-12-2009.html">a fait le point</a> sur l'état de la branche -staging et on peut lire la phrase suivante : « <i>Pilote Hyper V Microsoft. Les développeurs semblent avoir disparus une fois de plus, cela commence à être fatiguant. Marqué pour retrait dans le 2.6.35</i> ».
<br />
Pourtant le 20 janvier un message de Hank Janssen, développeur chez Microsoft, <a href="http://driverdev.linuxdriverproject.org/pipermail/devel/2010-January/003633.html">est apparu</a> sur la liste de diffusion du Linux Driver Project et à sa lecture on comprend mieux pourquoi, à Redmond, le travail sur ce pilote avance avec le rythme majestueux d'un glacier plutonien :
<br />
« <i>Le monde bouge lentement ici du côté sombre, mais des progrès sont en cours. J'ai finalement tiré les bons leviers en interne pour commencer à travailler sur la TODO list.
<br />
Oui c'est bien ça le grand trouble que vous avez senti dans la Force.
<br />
Encore une fois toutes mes excuses mais la taille des montagne qu'il faut bouger en interne pour nous permettre de travailler en vue d'une intégration dans la branche principale est proprement tectonique. Sans compter que ça a raccourci mon espérance de vie de plusieurs années :)
<br />
J'apprécie vraiment votre patience à tous. Nous sommes en train de changer, mais très lentement !</i> ».
<br />
</ul><h2><a name="bilan"></a>Le bilan en chiffres (<a href="#sommaire">↑</a>)</h2>
<br />
Côté statistiques, <a href="http://lwn.net/Articles/373405/">l'article récapitulatif pour le 2.6.33</a> du site LWN est disponible et on pourra également se reporter <a href="http://www.remword.com/kps_result/">au site dédié</a> aux statistiques du noyau Linux. Un autre <a href="http://lwn.net/Articles/374574/">article récent</a> du site LWN (accessible dès maintenant pour les abonnés et visible par tous à partir du jeudi 25 février) s'est également penché sur les statistiques cumulées depuis l'introduction du gestionnaire de version git, c'est-à-dire en avril 2005 avec la version 2.6.12-rc2.
<br />
<br />
Pour le noyau 2.6.33, le nombre de patchs était de 10 784 au 21 février (10 944 pour le 2.6.32). Il semble bien que l'équipe de développement de Linux se soit plus ou moins calée sur un rythme de développement qui représente un peu plus de dix mille patchs tous les trois mois, écrits par un peu plus de 1000 développeurs (1188 cette fois-ci).
<br />
En terme de lignes de codes, nous avons près d'un million et demi de changements (ajout de 900 000 lignes et suppression de 520 000 lignes).
<br />
Dans l'article récapitulant l'évolution entre le 2.6.12-rc2 et le 2.6.33 ("<a href="http://lwn.net/Articles/374574/">How old is our kernel?</a>"), on apprend notamment qu'en cinq ans le code du noyau Linux dans son ensemble a beaucoup changé puisqu'il ne reste plus que 31% des lignes de code du noyau actuel qui n'ont pas été modifiées depuis avril 2005. Les parties ayant le moins changé sont les sous-répertoires <i>documentation</i> (41% de code identique) et <i>sound</i> (45% de code identique). Le cœur du noyau quant à lui (<i>kernel</i>) ne contient plus que 13% de code datant du 2.6.12-rc2.
<br />
Une autre statistique intéressante à considérer est celle des primo-contributeurs (ceux qui ont fait un patch dans le noyau pour la toute première fois lors d'un cycle donné). Si on utilise les pages "First commit" du site <a href="http://www.remword.com/kps_result/">Linux Kernel Patch Statistic</a> on trouve les résultats suivants :
<br />
Noyau 2.6.27 : <a href="http://www.remword.com/kps_result/2_6_27_ftc.html">216</a> primo-contributeurs
<br />
Noyau 2.6.28 : <a href="http://www.remword.com/kps_result/2_6_28_ftc.html">252</a> primo-contributeurs
<br />
Noyau 2.6.29 : <a href="http://www.remword.com/kps_result/2_6_29_ftc.html">279</a> primo-contributeurs
<br />
Noyau 2.6.30 : <a href="http://www.remword.com/kps_result/2_6_30_ftc.html">256</a> primo-contributeurs
<br />
Noyau 2.6.31 : <a href="http://www.remword.com/kps_result/2_6_31_ftc.html">275</a> primo-contributeurs
<br />
Noyau 2.6.32 : <a href="http://www.remword.com/kps_result/2_6_32_ftc.html">294</a> primo-contributeurs
<br />
Noyau 2.6.33 : <a href="http://www.remword.com/kps_result/2_6_33_ftc.html">272</a> primo-contributeurs
<br />
<br />
On voit que chaque noyau enregistre la participation de plus de 250 nouvelles têtes à chaque fois, ce qui est rassurant pour la pérennité du modèle de développement utilisé.
<br />
<br />
Enfin, si on regarde les statistiques en terme de nombre de patchs nous pouvons pousser un franc cocorico, puisque c'est le français Frédéric Weisbecker (fweisbec sur LinuxFr) qui est <a href="http://www.remword.com/kps_result/2_6_33_petop.html">médaille d'or</a> dans cette version 2.6.33 avec un total impressionnant de 146 patchs ! On y retrouve le travail évoqué plus haut sur le traçage/profilage, la suppression du BKL dans reiserfs, ainsi que la réimplémentation de Hardware-breakpoint par dessus perf events.
<br />
Comme ces travaux me semblent particulièrement difficiles à comprendre et à expliquer (oui, ça s'est vu dans la dépêche que je patauge sur le tracing), j'ai pensé que Frédéric serait mieux à même d'en parler directement aux lecteurs de LinuxFr et que cela nous permettrait par la même occasion de mieux faire sa connaissance.
<br />
Je lui ai donc soumis une petite liste de questions auxquelles il a eu la gentillesse de répondre.
<br />
<br />
<h2><a name="fweisbec"></a>Questions/Réponses avec Frédéric Weisbecker (<a href="#sommaire">↑</a>)</h2>
<br />
<b>Patrick_g : Pourquoi avoir choisi de contribuer à Linux ? La GPL c'est important dans ton choix ou pas ?</b>
<br />
<br />
Frédéric Weisbecker : Pourquoi Linux ? D'abord parce que les noyaux sont ce qui me fascine le plus dans l'informatique. J'ai toujours voulu savoir comment mes logiciels contrôlaient mon matériel. Quand j'ai commencé à chercher des informations sur le sujet, c'étaient toujours des bribes disséminées un peu partout sur le web.
<br />
Je crois que c'est le côté cryptique de la chose qui est attirant, un peu pour la même raison que j'aime bien le reverse engineering :)
<br />
Partant de là, j'ai exploré le développement noyau sous Windows et Linux. Mais comme le noyau Windows est complètement obfusqué et que je n'y trouvais que des informations très schématiques, je ne m'y suis pas beaucoup attardé.
<br />
Linux étant open source, ça a été déterminant bien sûr, même s'il a fallu que je relise Linux Device Drivers ed.3 de nombreuses fois et que - même après - je ne comprenais toujours rien au code :)
<br />
<br />
Mais sa licence et surtout son développement ouvert (oui, oui, il y a des logiciels GPL/BSD/etc. qui ont un processus de développement tout à fait fermé) ont été très importants pour moi. C'est un processus très démocratique, qui fait qu'un inconnu lambda - comme je l'ai été en arrivant - peut participer lui aussi, pas besoin d'être employé par Red Hat ou Intel pour ça.
<br />
Bien sûr ce n'est pas une démocratie pure et parfaite, elle implique aussi une chaîne de confiance complexe avec des nœuds divers ayant plus ou moins de poids qui varie selon les sous-systèmes, mais tout de même, le plus gros poids reste dans le patch, je pense.
<br />
<br />
Ensuite, le côté logiciel libre et développement ouvert permet de vous faire un nom, visible rapidement sur le Web et qui reflète ce que vous avez fait. Si vous êtes étudiant en informatique et que vous voulez bosser dans un domaine particulier, prenez un logiciel libre dans ce domaine, et participez. La liste des bénéfices à en tirer est innombrable.
<br />
<br />
Autre chose : ça émousse aussi un peu le Complexe de la Momie. Si vous vouez votre vie au logiciel propriétaire, est-ce-que les gens pourront réutiliser votre travail ? À quel point ? Pendant combien de temps ?
<br />
Participer au logiciel libre implique le principe de "se hisser sur les épaules des géants", votre travail aura plus de chances d'être réutilisé, vous aurez agrandi le géant à votre tour et les briques laissées derrière votre passage auront plus de pérennité.
<br />
<br />
C'est aussi la raison pour laquelle je préfère les licences de type GPL aux licences BSD. Ça force plus le travail en commun. Plutôt que chacun réinvente le même moulin, des entreprises concurrentes qui bossent sur des produits éphémères se rejoignent tout de même sur un point commun, un travail à long terme, un truc particulier.
<br />
La GPL amène ça par la coercition, une œuvre qui fait réellement progresser les choses. Je pense que la BSD amène ça aussi, mais avec beaucoup moins d'efficacité.
<br />
<br />
<b>Patrick_g : Es-tu payé pour ton travail sur Linux ou travailles-tu sur ton temps libre ?</b>
<br />
<br />
Frédéric Weisbecker : Non, que du temps libre.
<br />
<br />
<b>Patrick_g : Si tu es bénévole as-tu reçu/t'attends-tu à recevoir des propositions de job à la suite de tes contributions ?</b>
<br />
<br />
Frédéric Weisbecker : Je n'ai pas reçu de propositions de job. Et je suis étudiant, alors jusque là je n'ai pas vraiment cherché. Mais je suis en fin de cursus, avec beaucoup de temps libre, donc si quelqu'un veut d'un développeur noyau (upstream de préférence) à mi-temps je suis preneur :)
<br />
<br />
<b>Patrick_g : La LKML a-t-elle été accueillante pour tes patchs ou y a-t-il eu des oppositions virulentes ?</b>
<br />
<br />
Frédéric Weisbecker : Selon les patchs, l'un ou l'autre. Et c'est le cas pour tous les développeurs du noyau, ce sera toujours comme ça et heureusement. Même les plus expérimentés se font refuser des patchs. Même les mainteneurs d'un sous-système peuvent se voir refuser des patchs dans le domaine qu'ils maintiennent.
<br />
En fait, il y a plusieurs niveaux de passage en revue d'un patch, par ordre de priorité :
<br />
<br />
1) Le changement répond-il à un vrai besoin ? Est-ce-qu'il résout un vrai problème, est-ce-que ce changement est utile?
<br />
<br />
2) Le changement répond-il d'une bonne manière à ce besoin ? Est-ce une bonne solution ? Devrait-on le faire autrement ?
<br />
<br />
3) L'architecture du nouveau code est-elle propre ?
<br />
<br />
4) Y a-t-il des fautes de code, des bugs, des problèmes de verrous, etc.
<br />
<br />
5) Le changement respecte-il les standards de style de Linux ? (espaces blancs, indentations, accolades mal placées, etc.)
<br />
<br />
Bien souvent, si le niveau n ne passe pas, le niveau n+1 ne sera même pas examiné.
<br />
Ceci étant, lorsque l'on devient familier avec un sous système particulier, on devient très à l'écoute de son cycle de vie, on a une meilleure vision globale de son code, des problèmes qui sont en suspens. On passe aussi en revue les patchs des autres et on découvre les problèmes qu'ils ont vu, ce qui en déterre d'autres, on découvre également les besoins des autres. À partir de là, l'étape 1 ne pose plus beaucoup de problèmes.
<br />
<br />
Reste l'étape 2. Si votre changement implique beaucoup de boulot (plus qu'une journée), surtout parlez-en d'abord sur LKML, voyez l'opinion générale sur l'architecture qui conviendrait le mieux avant de vous lancer, ou vous risquez de vous casser les dents après des jours, voire des mois de boulot. Lorsqu'on agit seul, même si l'on est familier avec le code en question, on a souvent une vision erratique et incomplète du problème ou de la solution à adopter.
<br />
Il faut entamer une discussion, et/ou proposer des maquettes très brouillonnes, à peine testées (patchs RFC), juste pour tâter l'opinion avant de se lancer pour de bon.
<br />
Souvent on passe l'étape 3 par la même occasion à force de proposer des patch RFC et de corriger à partir des commentaires donnés par les relecteurs sur LKML.
<br />
Le reste de l'étape 3, puis la 4 et 5 se résolvent à force d'adresser les commentaires des autres, après quelques versions du patch.
<br />
Ça peut aller jusqu'à prendre parfois une dizaine d'itérations, ça arrive...
<br />
Il est rare qu'un changement significatif soit accepté dès la première version.
<br />
<br />
<b>Patrick_g : Vas-tu continuer ton travail d'élimination du BKL dans d'autres coins du noyau que reiserfs ?</b>
<br />
<br />
Frédéric Weisbecker : Peut-être, oui. J'ai déjà enlevé quelques traces de bkl ailleurs que dans reiserfs.
<br />
Les restes de Bkl sont dans des vieux pilotes, donc difficiles à tester, mais aussi encore un peu dans le cœur du noyau : VFS, Block, TTY... Ce qui reste à supprimer dans le cœur est délicat, on ne sait pas toujours ce qu'il protège.
<br />
Ça donne lieu à beaucoup de "Pushdown". C'est-à-dire que lorsque l'on a :
<br />
<br />
lock_kernel();
<br />
func1();
<br />
unlock_kernel();
<br />
<br />
Si func1() est une callback(), on va descendre l'appel de la BKL dans toutes les instances de func1() (toutes les fonctions susceptibles d'être pointées par func1).
<br />
Ce sera plus facile de la supprimer après ça, car on finira au fur et à mesure par arriver à passer en revue chacune de ces fonctions, voir laquelle a besoin d'un verrou et remplacer par un verrou traditionnel si c'est le cas, sinon supprimer la bkl à cet endroit. Ce travail peut passer par un pushdown de plus en plus profond, jusqu'à ce qu'on aie une vision nette et chirugicale de ce qu'elle protège (lorsqu'elle protège quelque chose).
<br />
Si func1 est une fonction en dur, c'est le même principe, on pushdown sur les function que func1() appelle.
<br />
D'ailleurs ce travail donne l'illusion que la suppression du bkl n'avance pas. Si tu fais un grep sur lock_kernel dans les sources du noyau, tu trouveras peut être plus d'appels que dans une version précédente, mais en réalité il est pris moins souvent et plus sélectivement.
<br />
<br />
<b>Patrick_g : Ton patch "<a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=96a2c464de07d7c72988db851c029b204fc59108">bkl ftrace events</a>" peut-il permettre de faciliter le travail ?</b>
<br />
<br />
Frédéric Weisbecker : Non. Il permet de tracer l'activité de la bkl pendant que le système tourne. Ça permet de déterminer la fréquence de son usage dynamiquement, le temps durant lequel il est acquis, où et quand.
<br />
Si un grep lock_kernel est inefficace pour voir la progression de la suppression du bkl, en revanche les événements donnés par ces points de traçage par ftrace offrent une meilleure vue à ce niveau (pour une configuration de noyau donnée).
<br />
Ça peut aussi être utile pour quelqu'un qui a des pré-requis en termes de latence, vérifier le taux d'utilisation du bkl avec une configuration noyau donnée ou un matériel spécifique (dans le cas où un pilote utilise le bkl). Et également ça permet de voir à quel endroit on l'utilise le plus à l'exécution.
<br />
<br />
<b>Patrick_g : Pourquoi les gens de FreeBSD ont-ils réussi a enlever le BKL de TTY dans leur version 8.0 alors que Linux se traîne encore un code antique ?</b>
<br />
<br />
Frédéric Weisbecker : Héhé, bonne question. Je ne connais pas bien le code de FreeBSD.
<br />
Ceci dit, TTY est un sous-système maudit sous Linux. Je crois que peu de gens osent s'y aventurer, peut être parce que c'est le bordel, je ne sais pas trop. Je dois avouer que chaque fois que j'y vais, ça pique les yeux :)
<br />
Mais Alan Cox y a consacré beaucoup de temps. C'est l'un des seuls à bien connaître ce code, et il a, parait-il, assaini considérablement le code de tty et a supprimé beaucoup d'empreintes de Bkl dedans. Il en reste peu d'ailleurs. Il est surtout présent dans les évènements "hangups" de tty.
<br />
Malheureusement, Alan Cox a rendu son tablier de mainteneur de Tty, il y a quelques temps. Il devait en avoir marre. Ceci étant, il envoie encore des patchs pour TTY, notamment des pushdown de bkl dans les chemins de hangup :)
<br />
<br />
<b>Patrick_g : T'arrive-t-il de regarder le code des systèmes BSD pour comparer avec Linux ou bien est-ce terra incognita pour toi ?</b>
<br />
<br />
Frédéric Weisbecker : Terra incognita :)
<br />
<br />
<b>Patrick_g : Où en est la situation générale du tracing sous Linux à l'heure actuelle ? Le noyau est-il en retard sur DTrace ?</b>
<br />
<br />
Frédéric Weisbecker : Euh... je me sens un peu honteux. Mais je ne connais pas bien le tracing en dehors de ce qu'il y a sur la branche principale du noyau Linux. Mais bon je vais essayer de décrire un peu ce que je sais (ou ce que je crois savoir).
<br />
<br />
Premièrement, je ne sais strictement rien sur DTrace.
<br />
<br />
Le noyau Linux n'avait pas de sous-système de tracing avant 2.6.27. Mais il y avait beaucoup de mouvement dans des branches de développement avant cela, avec des orientations et des buts tout à fait différents :
<br />
<br />
- <span>LTTng</span>
<br />
Il y avait LTT, "Linux Tracing Toolkit", un patch <i>out of tree</i> avec des outils utilisateurs qui permettait de tracer l'utilisation du processeur. Je ne connais pas les détails, il s'agissait peut être de hooks sur l'ordonnanceur de tâches, entre autres.
<br />
Puis l'<a href="http://www.polymtl.ca/">Ecole Polytechnique de Montréal</a> a repris ce projet pour en faire LTTng (Linux Tracing Toolkit next generation) dont le développeur et mainteneur principal est Mathieu Desnoyers avec de multiples contributions par diverses compagnies comme Fujitsu, Sony, etc.
<br />
L'orientation principale de LTTng est de fournir un tracing qui tient bien le passage à l'échelle (utilisable même avec la multiplication de multi-cœurs, etc.), et un tracing fortement optimisé pour être même utilisable lorsque les services tournent, sans trop d'impact sur les performances. Ainsi on peut utiliser LTTng sans besoin d'interruption de service. Un utilisateur peut tracer son noyau sans impact sur le service qu'il offre à ses clients.
<br />
<br />
LTTng est basé sur les tracepoints (mergés d'ailleurs dans le noyau principal) et les markers, ainsi qu'un tampon circulaire qui centralise les données et enfin un jeu d'outils utilisateurs pour exploiter les événements tracés. Les tracepoints sont des points de traçage statiques dans le noyau. LTTng en a placés sur de multiples points clés du cœur du noyau (ordonnanceur, irqs, appels systèmes, timers, etc.) pour offrir une vue assez complète de ce qui se passe. Les outils utilisateurs synthétisent tout ça.
<br />
<br />
Mathieu a fait un très bon boulot. Il avait essayé à l'époque de bosser sur la branche principale plutôt qu'out-of-tree, mais je crois que ça s'est soldé par un échec. À cette époque, les développeurs du noyau ne considéraient peut-être pas encore l'importance des tracepoints statiques. Et avoir des points de traçage statiques un peu partout dans le noyau n'enchantait pas grand monde dans la branche principale.
<br />
Je ne sais pas exactement pourquoi. Peut être parce que l'importance du tracing était encore trop peu considérée à l'époque, à moins que ce ne soit parce que ces tracepoints étaient sortis de leur contexte et ne semblaient pas encore avoir d'application directe. Je ne sais pas.
<br />
<br />
Je ne sais pas non plus où Mathieu en est avec ses projets de "mainlining" de LTTng. Je pense que l'une des difficultés est peut être d'adapter LTTng en cohérence avec l'existant en amont : Ftrace.
<br />
<br />
- <span>SystemTap</span>
<br />
L'orientation de SystemTap est fortement basée sur le scripting et les tracepoints dynamiques.
<br />
Un utilisateur peut écrire un script (dans un langage dédié) pour extraire des évènements du noyau divers et variés, sortir des statistiques, etc. le tout sans besoin de tracepoints statiques.
<br />
Les tracepoints sont insérés dynamiquement par le biais d'un hot-patching (modification du code en mémoire).
<br />
Pour ça, Systemtap utilise kprobes (permet de créer/gérer des tracepoints dynamiques dans le noyau), et uprobes (même chose mais en espace utilisateur). Kprobes est mergé dans la branche principale, mais pas uprobes.
<br />
Il y a également, si je ne me trompe pas, un compilateur script -> bytecode et un interpréteur bytecode dans un module noyau (out of tree).
<br />
<br />
SystemTap est également basé sur utrace, un outil pour faciliter l'implantation de code pour gérer le traçage des processus, etc.
<br />
<br />
SystemTap n'est pas dans la branche principale car je crois qu'il y a eu des désaccords fondamentaux sur son architecture entre les développeurs de la branche principale et ceux de systemtap.
<br />
<br />
- <span>Ftrace</span>
<br />
Le patch Preempt-rt, la branche out of tree dédiée au développement de Linux pour en faire un noyau utilisable pour faire du temps réel soft, avait besoin de faire beaucoup de tracing afin de repérer les zones responsables de latences non voulues.
<br />
Quelques traceurs sont nés : un traceur de fonctions (responsable du nom ftrace), un traceur de zones non-préemptibles, un traceur d'événements de l'ordonnanceur, etc. écrits par Steven Rostedt, Ingo Molnar et d'autres.
<br />
Ces traceurs ont fini par former un sous-système à part entière, avec possibilité d'écrire de nouveaux traceurs sous forme de greffons. Le tout a été mis au propre et mergé dans la branche principale dans 2.6.27.
<br />
<br />
Ftrace est devenu plus qu'ftrace, et est maintenant le sous système de tracing de la branche principale. D'autres greffons ont été développés ou adaptés pour ftrace : traceur d'allocateur de mémoire, traceur d'évènements blocks, mmiotrace, un traceur de graphe de fonctions, etc. Le tout, tournant autour d'un tampon circulaire qui agglomère le tout et d'une interface debugfs.
<br />
<br />
- <span>Aujourd'hui</span>
<br />
Maintenant où en sommes nous? Justement les choses ont beaucoup évolué, le tracing est devenu un sujet très actif dans la branche principale.
<br />
<br />
Les tracepoints statiques ont pris beaucoup d'importance depuis qu'ils ont une nouvelle surcouche : les ftrace events. Ceux-ci permettent d'exploiter les tracepoints depuis debugfs. On peut les activer en utilisant des pseudo-fichiers et récupérer leurs traces facilement.
<br />
Donc l'insertion de tracepoints statiques dans le noyau se fait beaucoup plus allègrement. On a maintenant des tracepoints pour la plupart des points clés du cœur du noyau. Certains de ces efforts viennent d'ailleurs des développeurs de LTTng qui ont adapté certains de leurs tracepoints pour la branche principale.
<br />
<br />
Les tracepoints dynamiques ont également gagné en importance. Kprobes, qui jusque là n'avait pas d'utilisateur dans la branche principale, a gagné son interface utilisateur par le biais des ftrace events (permettant de créer des tracepoints statiques qui sont en fait virtuels : ce sont des tracepoints dynamiques).
<br />
<br />
2.6.31 a également vu arriver un nouveau sous-système de profiling : perf events (autrefois perf counters). Les tracepoints, qu'ils soient dynamiques ou statiques, peuvent maintenant être utilisés pour faire du profiling, voire pour coupler du tracing et du profiling, un outil très puissant. Et justement, on voit aujourd'hui arriver des changements permettant de scripter l'exploitation de ces évènements de tracing par le biais de scripts python ou perl.
<br />
L'utilisation de filtres dans les événements de ftrace, couplés avec ce genre de scripting, nous rapproche finalement des buts de SystemTap, mais avec des langages connus, bien que les choses ne se fassent finalement pas au même niveau d'action.
<br />
<br />
Parallèlement, les développeurs de SystemTap ont fait des tentatives pour merger utrace, sans trop de succès étant donné le manque de couche d'utilisation existante de utrace dans la branche principale, ainsi que des divergences d'opinions sur son architecture et son rôle.
<br />
Utrace génère des doutes et est décrié par les développeurs de la branche principale qui le taxent de "machine à tout faire sans rôle clairement défini" (traduction grossière de ce qu'en dit Linus).
<br />
<br />
Voyant la puissance offerte par l'utilisation de kprobes en utilisant perf events et ftrace, on commence à vouloir explorer les tracepoints dynamiques sur les processus utilisateurs. Exactement ce que fait uprobes. Uprobes a donc été proposé récemment pour la branche principale.
<br />
Beaucoup de controverses ont été levées : la dépendance à utrace par uprobes, son interface ftrace à renouveler pour pouvoir l'exploiter avec perf events, l'architecture du hot patching : divergences d'opinions sur la manière de rebondir sur l'application utilisateur après déclenchement d'un hook. Mais il y a fort à parier que uprobes fera son chemin un jour dans la branche principale, étant donnée la puissance de ce genre d'outil.
<br />
<br />
Il y a également encore beaucoup de choses en prévisions, ex. : utilisation du traceur de fonctions pour faire du profiling par fonction avec perf events, par exemple (compter les cache-hit, cache-miss au sein d'une fonction, entre autres possibilités).
<br />
<br />
<b>Patrick_g : Entre les patchs sur l'élimination du BKL, ton travail sur les hw-breakpoints et celui sur le profilage et le tracing tu as touché des parties compliquées et diverses du noyau. Es-tu surhumain ?</b>
<br />
<br />
Frédéric Weisbecker : Héhé :) Non. En fait j'ai eu la chance de bosser sur des sous-systèmes jeunes, voire naissants.
<br />
Essayez de travailler sur l'ordonnanceur de tâches, par exemple. Je pense que c'est difficile parce que CFS (l'ordonnanceur actuel) a été mergé il y a quelques cycles déjà. C'est un gros morceau qui a eu le temps de se stabiliser et de mûrir. Il y a certainement des choses à faire encore, mais pour un nouveau venu ça prendra un peu de temps de se familiariser avec ses milliers de lignes de code qui ont déjà de la bouteille. C'est tout à fait possible, ça demandera juste du temps.
<br />
<br />
Or, si vous arrivez sur le développement d'un nouveau sous-système, ou d'une grosse refonte d'un sous-système, c'est du code encore frais, plein de bugs, plein de choses à améliorer, à augmenter, à repenser. Il suffit de compiler, tester et les bugs viennent tout seuls, plus qu'à envoyer les patchs pour corriger les problèmes.
<br />
Quand on commence cet engrenage, on se familiarise très vite avec le code en question, et des idées d'améliorations plus larges viennent avec le temps étant donnée la meilleure compréhension du sous-système que l'on gagne, et les relations/suggestions/plaintes des autres développeurs ou utilisateurs.
<br />
C'est ce qui m'est arrivé avec ftrace qui venait d'être mergé quand je suis arrivé. Pareil avec perf events (d'autant qu'il y avait besoin de créer un pont avec ftrace, que je connaissais déjà bien).
<br />
Idem avec les hardware breakpoints, une nouvelle API générique proposée par K. Prasad que nous avons rediscutée, puis améliorée à partir de sa version.
<br />
Pour reiserfs, c'est plus du hasard. Je pensais que ça prendrait juste un après-midi pour transformer le BKL en un mutex.
<br />
Plus je corrigeais les bugs dûs à la conversion, plus je me disais "nan mais après ce patch là ce sera bon, ça marchera, c'est le dernier".
<br />
Finalement, ça m'a pris plusieurs mois, j'ai vraiment mal anticipé la tâche :)
<br />
<br />
<b>Patrick_g : Merci encore Frédéric d'avoir pris le temps de répondre à mes questions.</b>
<br />
<br />
<h2><a name="pour_la_suite"></a>Pour la suite (<a href="#sommaire">↑</a>)</h2>
<br />
En ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers <a href="http://www.linuxfoundation.org/en/Linux_Weather_Forecast">la page spécifique</a> de la Fondation Linux et surtout vers <a href="http://lwn.net/Articles/367787/">cet article</a> du site Linux Weekly News qui désigne deux candidats évidents.
<br />
<h3>Ceph</h3>
<br />
<a href="http://lwn.net/Articles/258516/">Ceph</a> est un système de fichiers distribué qui à l'ambition de pouvoir évoluer et monter en charge sans aucun problème. Cette capacité à absorber la charge (en terme d'utilisateurs simultanés) et à évoluer en taille (en terme de disques connectés) représente les deux points forts de Ceph qui est issu de la <a href="http://ceph.newdream.net/publications/">thèse de doctorat</a> de son concepteur Sage Weil.
<br />
Pour atteindre <a href="http://ceph.newdream.net/about/">ses objectifs</a> Ceph migre automatiquement les données sur les différents disques afin d'avoir une bonne répartition des accès sans "point chaud". Il n'y a pas de disque de secours spécifique et, en cas de nécessité, la récupération des données se fait à partir de dizaines de disques simultanément et à destination de dizaines d'autres disques (N-way replication).
<br />
Une particularité de Ceph est qu'il existe des serveurs de méta-données (MDS pour MetaData Server) qui sont séparés des serveurs de données (OSD pour Object Storage Devices). Ils servent à répartir intelligemment les données, journalisent les modifications et permettent de s'adapter dynamiquement à la charge (dynamic scaling).
<br />
Ce fonctionnement ressemble un peu à celui du système de fichiers <a href="http://en.wikipedia.org/wiki/Lustre_%28file_system%29">Lustre</a> et Ceph, avec le slogan "scale from gigabytes to petabytes and beyond", vise clairement à devenir un concurrent <a href="http://news.ycombinator.com/item?id=1069699">plus facile à administrer</a>.
<br />
L'opportunité d'intégrer la branche principale du noyau a été manquée lors de la "fenêtre de tir" du 2.6.33 pour diverses raisons dont la plus visible est le refus de Linus de se laisser impressionner par la liste des fonctions. <a href="http://thread.gmane.org/gmane.linux.file-systems/37252/focus=37411">Son message</a> détaillé est très intéressant à lire car il explique ce qui motive son choix d'inclure ou pas une nouvelle fonction dans le noyau : « <i>Quand il s'agit d'ajouter tout un nouveau morceau de code ma réponse par défaut est toujours "non". Il faut d'abord m'expliquer pourquoi je _dois_ inclure ce truc</i> ».
<br />
<br />
<h3>AlacrityVM</h3>
<br />
S'il est probable que Ceph sera ajouté rapidement au noyau, la situation est beaucoup moins rose pour <a href="http://developer.novell.com/wiki/index.php/AlacrityVM">AlacrityVM</a> et la bataille fait rage entre les développeurs. <a href="http://lwn.net/Articles/345296/">AlacrityVM</a> est une nouvelle proposition (encore une !) dans le domaine de la virtualisation puisqu'il s'agit d'un dérivé de <a href="http://fr.wikipedia.org/wiki/Kernel-based_Virtual_Machine">KVM</a> qui se concentre sur les performances dans le domaine des entrées/sorties. Le but de Novell, qui est derrière le projet, est d'arriver à un débit équivalent aux spécifications maximales du matériel et d'obtenir une virtualisation sans aucun impact négatif en terme de performances. Le code se base sur une utilisation directe des pilotes d'entrées/sorties au lieu de passer par des pilotes émulés. Ces deux schémas successifs (<a href="http://developer.novell.com/wiki/index.php/Image:Kvm_interactions-emulation.jpg">avant</a> - <a href="http://developer.novell.com/wiki/index.php/Image:Kvm_interactions-direct.jpg">après</a>) aident à comprendre la logique du développement d'AlacrityVM.
<br />
L'ennui c'est que les développeurs de KVM ne sont pas très contents de cette solution qui constitue essentiellement un "fork" de leur code. Ils réclament un travail en commun plutôt que l'écriture d'une nouvelle solution complètement séparée. Ingo Molnar <a href="http://article.gmane.org/gmane.comp.emulators.kvm.devel/44268">semble leur donner raison</a> puisqu'il signale que : « <i>Ces patchs ont reçus de multiples objections par les gens de KVM, pour des raisons techniques, car cela consiste basiquement à forker tous les pilotes KVM sans qu'aucune raison convaincante n'ait été apportée dans une discussion s'étendant sur plus de cent messages. Le résultat serait à mon humble avis un désagrément pour les utilisateurs car nous aurions deux infrastructures, des incompatibilités d'outils, etc.</i> ».
<br />
Ce message d'Ingo a relancé la bataille et une magnifique <a href="http://thread.gmane.org/gmane.linux.kernel/923880">flame war</a> s'est développée sur la LKML.
<br />
Comme c'est toujours Linus qui prend la décision finale, il a choisi de ne pas inclure AlacrityVM dans le noyau 2.6.33 et d'attendre que la poussière retombe un peu avant de choisir.
<br />
<a href="http://article.gmane.org/gmane.linux.kernel/931311">Son message</a> explique bien, avec son ton inimitable, quelle est sa position :
<br />
« <i>Les gens de la virtualisation discutent toujours à propos des 36 000 façons différentes qu'il y a de faire les choses. Au lieu de se concentrer sur les vrais pilotes, là où s'exerce vraiment la contrainte due au matériel, ils semblent se complaire à créer de nouvelles interfaces à un rythme hebdomadaire.
<br />
Quand je vois une nouvelle interface de virtualisation, je voudrais que les spécialistes se disputent à son sujet _entre eux_. Du fait que, personnellement, je ne me soucie absolument pas le moins du monde de la virtualisation, je peux prendre un peu de recul et admirer le feu d'artifice. Cela ne veut pas dire que ça ne m'amuse pas, j'aime bien une flame war à l'occasion, mais pour être vraiment impliqué dans une flame war, il faut que j'y attache assez d'importance pour m'enflammer à ce sujet.
<br />
Donc je ne veux pas que cette bataille se déroule dans mon dépôt et je préférerais vraiment que les combats s'achèvent _avant_ que je ne merge.
<br />
Vous êtes tous des malades les gars.</i> ».</a></li></ul></div><div><a href="https://linuxfr.org/news/nouvelle-version-2633-du-noyau-linux.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/25508/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/nouvelle-version-2633-du-noyau-linux#comments">ouvrir dans le navigateur</a>
</p>
patrick_ghttps://linuxfr.org/nodes/25508/comments.atom