David S. Miller est l'une des huiles du développement noyau Linux. Il est le responsable principal de l'implémentation SPARC de Linux et développeur principal de la pile TCP/IP. Il est également un acteur très impliqué dans le développement de GCC. Il nous fait l'honneur de répondre à nos questions.
GLMF : Pouvez-vous vous présenter et nous parler de la manière dont vous avez découvert Linux ?
David S. Miller : Mon nom est David S. Miller, je vis à Seattle.
Je hacke des trucs en open source depuis à peu près 15 ans, et j'ai découvert Linux en lisant des groupes Usenet, il y a un paquet d'années.
En fait, à ce moment-là, j'étais principalement intéressé par les machines de la série Atari ST et je lisais donc les groupes en rapport avec Atari.
Le portage m68k de Linux, sur lequel travaillaient des gens comme Hamish Macdonald, y faisait l'objet de discussions. J'ai donc commencé à approfondir le sujet.
Le portage m68k était un vrai chemin de croix à installer. J'ai donc fini par me tourner vers une première installation sur le 486 de mon père. Il s'agissait d'une des premières distributions SLS (je pense que c'était la version 1.03). L'installation complète demandait une trentaine de disquettes ou quelque chose dans le genre. Si je me rappelle bien, le noyau était un 0.99pl15.
GLMF : Quand avez-vous décidé de prendre part au projet ?
DSM : Ce n'était pas une décision, c'est arrivé naturellement.
À ce moment-là, je commençais à jeter un œil à Linux. Le code en espace utilisateur passait tout juste du format binaire A.OUT à ELF. H. J. Liu et Eric Youngdale avaient achevé la plus grande partie de ce travail.
Un excellent test en espace utilisateur se résumait à la capacité à bootstraper Emacs. La raison de ce choix comme élément du processus de développement était qu'Emacs s'exécute lui-même, procède à quelques initialisations et, ensuite, dumpe l'image résultante en un exécutable final. Ce processus est appelé « unexecing ».
Quoi qu'il en soit, j'avais le support initial ELF qui fonctionnait sur le PC de mon père et j'essayais de faire en sorte qu'Emacs se dumpe lui-même de manière viable. J'étais coincé et j'ai donc configuré mon compte à l'université de sorte qu'Eric Youngdale puisse se connecter et faire fonctionner tout cela. Un jour où deux plus tard, c'était chose faite. Il avait réussi.
Après cela, mon intérêt s'est tourné vers le portage Sparc, puisque j'avais accès à bon nombre de matériels intéressants à la Rutgers University. J'ai fait booter Linux sur Sparc, j'ai mis en route la liste de diffusion et je me suis également occupé du code réseau.
GLMF : Quelle question vous énerve le plus sur une liste de diffusion ?
DSM : Fondamentalement, tout ce qui ressemble à des trolls. La plus anti-sociale des choses que vous puissiez faire au monde est d'interrompre un groupe de personnes productives et leur faire perdre leur temps.
Dans les faits, un certain nombre de personnes voient leurs adresses bloquées (au moins temporairement) dans les listes de diffusion en raison d'incidents « trollesques » assez négatifs. Ce qu'il y a de plus remarquable, c'est que quelques-uns d'entre eux essaient encore de manipuler pour voir le blocage retiré.
Par exemple, disons qu'une personne qui trolle sans cesse depuis des jours se fait bannir et que, finalement, après quelques jours ou semaines, elle comprend ce qui vient de se passer. Ainsi, elle va envoyer un message privé à des gens comme moi, Linus Torvalds, Andrew Morton, etc. Ceci en disant : « Eh ! J'essaie d'envoyer un rapport de bogue utile à la liste de diffusion et je suis banni. S'il vous plait réhabilitez-moi, je veux contribuer.» La bonne blague !
C'est manipulateur, mais les gens le font.
GLMF : Quel est le meilleur retour que vous ayez eu jusqu'ici ?
DSM : J'aime le retour que je reçois des utilisateurs et des autres personnes qui utilisent mon travail.
Mais, pour être parfaitement honnête, rien ne vaut le fait de recevoir un retour d'un pair. N'importe quoi de positif que je reçois des autres core-développeurs a tendance à faire mon bonheur.
GLMF : De quoi êtes-vous responsable dans le noyau Linux ?
Dans les faits, je m'occupe du réseau et du/des portages Sparc.
Le support réseau occupe la majorité de mon temps. C'est amusant, car parfois je passe tellement de temps avec la gestion des patchs qu'à la fin de la journée je n'ai plus d'énergie pour quoi que ce soit d'autre. En particulier, plus d'énergie pour mon propre travail.
Bien entendu, je ne laisse pas cela arriver trop souvent, sinon je vais devenir vieux et ennuyeux avant l'heure.
Le portage Sparc est à la fois amusant et un véritable challenge. Étant donné que j'écris la plupart du code pour le portage sparc64, n'importe quel problème est de mon fait et uniquement de mon fait :)
Je pense qu'il est important d'être extrêmement communicant en tant que responsable d'un sous-système. Lorsqu'on est en semaine, toujours au moins donner un feedback pour chaque soumission de patch dans la journée. Lorsque les gens doivent attendre plus d'un jour pour recevoir un retour sur leur travail, cela devient stressant et, parfois, cela à tendance à vraiment les énerver.
Donc, si l'objectif est de voir davantage de personnes contribuer, répondez rapidement. Vous devez vraiment être capable d'investir du temps là-dedans et j'ai réalisé que la plupart des gens n'en sont pas capables. Ne vous faites pas appeler « responsable » si ce n'est pas le cas.
GLMF : Combien de temps par jour en moyenne passez-vous sur les mails ?
DSM : Cela me prend généralement une heure juste pour parcourir mes messages en début de chaque journée. Et ce n'est même pas vraiment lire quoi que ce soit. C'est tout juste trier et faire une première passe pour effacer ce qui ne m'intéresse clairement pas.
La plupart de ces messages sont destinés au postmaster de vger.kernel.org. Ainsi, dans cette première passe, je cherche également les problèmes de rebond et les choses de ce type.
J'ai habituellement besoin d'un autre café juste après cette première heure :-)
GLMF : De combien de temps disposez-vous pour implémenter vos propres idées ?
DSM : Bonne question.
Je fonctionne selon deux modes. Dans le premier mode, je m'attaque à la liste des patchs pour le réseau et le support Sparc de manière intensive et je ne fais presque rien sur mon propre travail.
Dans l'autre mode, je traite les patchs comme nécessaires, mais j'essaie de faire en sorte que d'autres personnes prennent soin de la gestion. Résultat, je peux passer la plupart de mon temps sur des idées qui m'intéressent.
Ainsi, dans le premier mode, je dois passer peut-être une heure ou deux au mieux. Dans le second mode, je peux passer la majorité de ma journée sur mon propre code.
Ce sont des phases qui vont et viennent. Je peux m'éclater sur l'implémentation de quelque chose qui m'est propre pendant deux semaines, puis, passer un mois à m'occuper des soumissions de patch intensément.
Cela dépend également d’où nous en sommes dans le développement du noyau. Ceci a une énorme influence sur mes priorités.
GLMF : Pouvez-vous nous en dire plus sur votre travail sur le Multiqueue Networking de Linux ?
DSM : Ceci prend énormément de temps. La base du support réseau est à jour du point de vue des facilités multiqueue que proposent les différents périphériques.
Dans un premier temps, nous avons facilité le support des pilotes de périphériques supportant le multiqueue du côté réception. Relativement parlant, c'était bien plus facile que la partie émission. C'était surtout une question de dégager les structures de données. Ce travail a été fait majoritairement par Stephen Hemminger.
Je récolte un peu plus les lauriers pour le support du côté émission multiqueue, mais, encore une fois, une importante quantité de personnes m'ont retourné des informations et corrigé les bogues. Aucun homme n'est une île (NDRL : « No man is an island », proverbe américain) en particulier pour les tâches importantes dans le noyau.
Le multiqueue en émission était bien plus difficile, car il a de graves implications sur le scheduler. Par exemple, dans une configuration multiqueue, quelle sémantique souhaitez-vous utiliser pour la classification et le contrôle de la bande passante dans le scheduler ? Est-ce que les classes de trafic sont encore par périphérique ou les considérez-vous à présent par queue ?
Ceci est important, puisqu'il y a une implication pour les performances et pour le comportement de la configuration.
Pour l'heure, nous gardons ce genre de chose en rapport avec le périphérique, comme cela a toujours été le cas. Mais, c'est un simple exemple des nombreuses questions sémantiques qui doivent trouver une réponse pour le support multiqueue en émission.
GLMF : Qu'est ce qui doit être amélioré dans Qdisc pour vous aider dans le travail sur multiqueue ? Est-ce qu'il reste un travail sur RCU (Read-copy-update) à faire comme votre dernière présentation à Seattle le laisse entendre ?
Il y a pas mal de problèmes de locking relativement complexes en rapport avec le chemin d'émission au travers du scheduler et du périphérique.
À la fois Qdics et le pilote de périphérique (TX) ont un locking différent. De plus, les requêtes de configuration de l'utilisateur arrivent pour le scheduler de paquets et ces requêtes demandent que l'arbre complet des objets Qdisc ne change pas durant ces opérations.
Au départ, il était établi que l'utilisation plus intensive de RCU aiderait, mais, en vérité, il est apparu qu'il était plus difficile et plus complexe si nous nous reposions uniquement sur RCU.
Nous n’utilisons RCU que pour la visibilité du pointeur vers la racine Qdisc attachée à un périphérique. Lorsque nous voulons changer la racine Qdisc, nous assignons le pointeur et attendons une période d'inactivité RCU. Cette période nous permet de nous assurer qu'aucun chemin de transmission asynchrone n'utilise encore le précédent objet Qdisc.
Pour la plupart du travail, nous utilisons le locking traditionnel. Nous partons du principe, pour l'instant, d'un point de vue Qdisc, qu'à partir du moment où vous bloquez la racine d'un arbre Qdisc avec cette méthode, tout ce qui se trouve en dessous restera en place.
GLMF : Est-il encore nécessaire de toucher au code des pilotes actuellement ?
DSM : Oui, tout le temps et pas uniquement pour les pilotes que j'ai écrits.
Nous avons beaucoup d'interfaces pour lesquelles nous cherchons des améliorations au cas par cas. À la fois parce qu'elles sont affreuses, pénibles à maintenir ou tout simplement inefficaces.
Lorsque cela se passe sur les interfaces de pilotes, il est nécessaire de toucher à pas mal de pilotes eux-mêmes.
Par exemple, si vous voulez faire des changements dans la méthode ->hard_start_xmit(), il faut toucher à pas loin de 500 pilotes.
Il m'est déjà arriver de faire ce genre de changement massif pour finalement me rendre compte que mon idée ne fonctionnait pas. Ainsi, j'ai dû annuler tous les changements effectués.
C'est une très bonne expérience d'un point de vue pédagogique :-)
GLMF : Est-ce que vous ou votre société prenez du temps pour jeter un œil à ce que les autres systèmes font pour influencer votre travail ?
DSM : Pas vraiment.
Je regarde dans les sources librement disponibles du noyau BSD, mais uniquement pour chercher des choses en rapport avec la sémantique des sockets visibles par les utilisateurs.
C'était déjà ainsi, même lorsque le noyau Linux ne couvrait pas certaines fonctionnalités. Ce n'est pas comme si j'avais pour habitude de fouiller et que j'avais arrêté en devenant gentil.
Il y a plus que suffisamment de personnes qui contribuent et apportent des idées fraîches dans le noyau Linux pour me tenir occupé.
