Et voilà, depuis les temps immémoriaux (enfin, depuis au moins cinq ans) ou le gentil Dan Langille fait tout son possible et même plus pour rendre nos mois de mai plus beaux, plus sympa, et plus instructifs, il est arrivé ce qui devait arriver, et qui arrive toujours trop vite. Qu’est-il arrivé me direz-vous, (pour peu que vous n’ayez pas lu le titre du billet, ou que vous soyez complètement idiots), et bien, bande de dégénérés, en ce matin radieux, ou le soleil brille, les écureuils font leur boulot d’écureuil, les oiseaux chantent, et les bsdistes se réveillent doucement, il est arrivé ce qui devait arriver, nous voici arrivé le deuxième et bien malheureusement dernier jour de BSDCan ’08.
Et donc, après un petit déjeuner rapide, mais copieux, ou le cholestérol coula à flot, à la cafétéria de la résidence, je suis allé faire une petit tour en ville, (oui, je suis déjà en ville, mais ça sonnait bien,) et faire quelques courses pour ceux qui m’avaient commandé des choses. (Mais comment vais-je ramener tout ce sirop d’érable…) Pour ne toujours rien gâcher, il fait encore très beau. Les courses faites, et mes poumons remplis du grand air du matin Canadien, je pense que je vais me diriger doucement vers SITE et m’allonger dans l’herbe en attendant que les conférences commencent à 10h…
Je commence aujourd’hui par Up close and personal with TCP in FreeBSD par
Lawrence Stewart, et plus précisément le nouveau framework modulaire de
controle de congestion TCP. Il commence par un récapitulatif de l’histoire de
tout ce qui touche a la gestion de la congestion, quelques RFC, les
algorithmes, démarrage lent, congestion avoidance, retransmission rapide et
récupération rapide. Puis, la pile TCP d’aujourd’hui, NewReno, qui a
quelques petits problèmes sur les gros liens du au démarrage lent, ou encore
les nouveautés comme l’autoconfiguration de la taille du tampon de sockets.
Pourquoi faire un framework modulaire pour la congestion ? Ça facilite la
recherche et le processus de standardisation, ça permet d’avoir une KPI/API
simple. Ajout d’un arbre de sysctl net.inet.tcp.cc avec des variables
available qui est une liste des algo disponibles, et algorithm qui est
l’algorighme en cours d’utilisation. Cas d’étude, H-TCP, une implémentation
haute vitesse de TCP, environ 280 lignes de C, dont 180 pour l’algorithme en
lui même. Il présente ensuite quelques outils/modules noyau qui permettent de
s’intercaller dans la pile IP pour regarder ce qu’il se passe.
Ensuite, Brooks Davis nous parle de Using FreeBSD to Promote Open Source Development Methods. Qui nous parle de l’endroit où il travaille, The Aerospace Corporation ou plus de 12000 ingénieurs travaillent sur a peu près tous les domaines possibles et imaginables. (Comme par exemple, des roulements, mais, des qui fonctionnent de -120°C à +300°C et qui durent 40 ans, parce qu’on ne va pas envoyer de réparateur, et non, Hubble était la seule exception à cette règle.) Dans la culture du développement logiciel, il explique qu’en général, les logiciels sont conçus pour résoudre les problèmes d’aujourd’hui mais qui finissent par durer des dizaines d’années, ou qui utilisent des ressources minimales, le dépot central étant un serveur de fichier et les locks son gérés sur un bout de papier. Cela crée beaucoup de problèmes, il y a du code partout, avec plein de copies, de qualités très variables, et du code archaïque, qui utilise parfois des fonctionnalités maintenant inexistantes. La plupart du temps, il n’y a pas de contrôle de version avec tout ce que ça implique. Dans le monde du logiciel libre, les méthodes ne sont pas les mêmes, parce qu’il faut travailler en équipe, depuis n’importe où sur terre, (pour l’instant,) et ça permet en général d’avoir du code bien meilleur. Les logiciels d’entreprises peuvent tout à fait devenir des logiciels ouverts, et les logiciels ouverts peuvent devenir, parfois avec des modifications, des logiciels d’entreprise. Ils ont donc décidé de créer une sorte de SourceForge interne pour donner aux développeurs des moyens communs, en utilisant FreeBSD, PostgreSQL, Apache, Subversion et Trac. Les objections qu’ils ont reçu étaient du genre : «mais c’est mon code,» alors que non, c’est celui de l’entreprise, où «je suis le seul à le comprendre,» mais tes collegues ne sont pas idiots, où «je suis le seul à pouvoir l’utiliser,» pourtant avec une documentation, ça doit être faisable… Pour conclure, de plus en plus de gens utilisent AeroSource, les méthodes open sources sont attractives, et les outils libres, et c’est plutôt une réussite.
C’est l’heure du déjeuner, ça tombe bien, parce que, en prenant un petit déjeuner à 7h30 le matin, je ne comprends pas qu’on puisse tenir jusqu’à midi et que des millions de gens fassent ça. Je vais donc aller déjeuner, m’allonger dans l’herbe, et bronzer un peu en évitant de prendre un coup de soleil. (Je pense que je n’étais pas loin de terminer la journée rose comme un homard un peu trop mûr.)
Il est par conséquent l’heure de retourner dans l’amphi, et de trouver une
place pas trop loin d’une prise de courant pour écouter DTrace for FreeBSD
par John Birrell. DTrace est un framework dynamique qui permet de tracer
toutes sortes de choses sans avoir besoin d’accéder aux sources ou de
recompiler en mode debug, il fonctionne «en vol» et les sondes sont insérées
et supprimées sans interruption. Une fois lancé, aucun processus ne peut
vraiment se protéger contre ces sondes. DTrace nous vient de Solaris, et est
disponible pour d’autres systèmes d’exploitation via OpenSolaris, ce n’est pas
sous licence BSD, mais CDDL, et ça peut poser des problèmes pour ceux qui
distribuent des binaires. DTrace n’est pas un débugger, il ne contient pas non
plus d’intelligence et est juste un logiciel simple qu’il faut programmer pour
avoir ce qu’on veut. DTrace est composé de fournisseurs et de sondes. Une
sonde est un objet qui lors qu’activé et déclenché envoie des données au
framework. Un fournisseur fabrique ou fournit des sondes à dtrace(9) via une
API, détermine comment les sondes sont nommées. Ensuite, il nous fait une
démonstration de DTrace et de ce qu’on peut récupérer comme informations. Le
langage D utilisé à l’air plutôt suffisant pour tout ce qui me vient à
l’esprit, il contient des actions qui permettent d’extraire des informations,
mais aussi des actions destructives qui peuvent tripoter l’état d’un
processus, des sousfonctions comme bcopy, strlen, rand, ce genre de
choses. On peut aussi accéder à toutes les variables qui sont dans le noyau ou
dans les modules. On peut faire des choses rigolotes, comme afficher toutes
les 5 secondes les 10 appels systèmes les plus utilisés avec leur nombre
d’appels, ou afficher toutes les secondes l’uptime de la machine. Et ça arrive
dans -CURRENT d’ici une semaine, et puis intégré à 7.x et 6.x dans les deux
semaines qui suivent.
Puis, John Baldwin nous fait une
Introduction to Debugging the FreeBSD Kernel.
Pour commencer, il y a déjà pas mal de documentation sur ce sujet,
dans le Developpers’s Handbook, il y a un chapitre entier sur le debug du
noyau, il y a aussi la page man de ddb(4), et la documentation de gdb. Tout
d’abord, DDB, permet d’étudier les points de blocages avec pour un types de
locks show thread, show turnstile et show lockchain et pour un autre
type, show sleepchain. DDB permet aussi d’ajouter des commandes avec
DB_COMMAND() et si la commande doit afficher des choses,
DB_SHOW_COMMAND(). On peut aussi utiliser la table de symboles avec
db_search_symbol() et db_symbol_values() pour trouver le symbole le plus
proche d’une adresse et l’afficher. Maintenant, kgdb, ou comment débugger un
noyau post-mortem, (en général,) et pour simplifier un peu les choses, kgdb
traite les modules noyau comme étant des bibliothèques partagées. On peut
aussi étendre kgdb avec des scripts, même si il y a certains points noirs
comme le fait qu’il n’y a pas de moyen de savoir combien on a reçu
d’arguments, qu’il n’y a pas de variables locales avec une visibilité locale,
(donc, il faut éviter la récursion, sinon, on perds ses arguments originaux,)
ou qu’on ne peut pas arrêter une commande définie par l’utilisateur. Bon, tout
ça c’est bien beau, mais mon noyau a fait boum, j’ai un joli crash dump,
qu’est ce qui s’est passé, en général, donc, c’est du à un défaut de page du à
une structure corrompue, à un manque de ressources, et dans le cas ou le
panic() semble étrange, c’est en général du au matériel. Mais moi, mon noyau
n’a pas fait boum, il s’est juste figé, et bien, il y a peut être des messages
sur la console, comme un manque de ressources, on peut aussi lancer DDB et
essayer de regarder ce qu’il se passe avec ps, etc, où plus simplement,
obtenir un crash dump pour faire une autopsie plus tard.
Et en enfin, Daniel Braniss nous parle de iSCSI. (Les slides sont en Comic Sans, ça commence bien.) Qu’est donc que iSCSI ? Il parait que c’est pour Internet Small Computer System Interface. Et bien, dans l’idée, c’est de remplacer les jolis cables avec les jolis connecteurs par des cibles virtuelles, a travers du réseau. la RFC iSCSI est la 3720, elle fait 257 pages, et elle contient 7226 de code ce qui fait qu’environ la moitié de la RFC est du code. Il parle des soucis qu’il à eu en écrivant l’initiateur iSCSI pour FreeBSD, et du mal qu’il a eu pour avoir de l’aide quand il a eu des questions et qu’il les a soumises sur les différentes listes. Et sinon, c’est dans les ports, et ça marche.
Enfin, pour terminer, Robert Watson nous présente une session de Works In Progress et Dan Langille nous fait rire, en donnant un t-shirt au plus jeune, qui a 19 ans, et au plus vieux, qui a plus de 60 ans. Ensuite, il remercie les sponsors, le programme committee, ceux qui l’ont aidé, ses parents, et passe la parole à Robert. Donc les WiP, 5 minutes chacun, ceux qui font plus court ont droit à des questions :
ps
par exemple, support bsnmpd, et ajouter des limites de ressources.src/tools/tools/mctest et ça à l’air très
bien. PCS a été amélioré, supporte l’IGMP maintenant. PCS est dans le Google
SoC, avec Victor Hugo Bilouro comme étudiant.Dan prends la parole organise la journée de demain pour les touristes. Les raisons pour lesquelle on vient, la bière, le contact, les salons, et la bière. Et je n’arriverai pas a raconter la suite, parce que je rigole trop. Maintenant, l’enchère habituelle, des calepins verts Google, j’en ai «gagné» un pour CAN$15, ensuite sont venu des broches google qui clignotent, des stylos google par pack de 5, puis à l’unité. Suit une casquette de la Fondation FreeBSD spéciale pour quand il pleut un peu, mais pas trop, signée par tous les core members qui sont là avec un peu d’ADN de Dan, qui a été adjugée à Randi Harper pour la modique somme de CAN$260. Ensuite, un T-Shirt OpenBSD qui est décrit comme étant le seul équipement anti-transpiration dans Ottawa aujourd’hui, pour CAN$40, puis deux T-Shirts BSDCan signés par core pour 120€ et l’autre CAN$60, le tout ayant rapporté dans les CAN$1000, pour la Mission d’Ottawa.
That’s all folks, et vivement l’année prochaine.