Kernel Summit et Linux Symposium

Posté par (page perso) . Modéré par Mouns.
Tags :
0
27
juil.
2006
Noyau
Comme tous les ans, un double évènement regroupant de nombreux développeurs du noyau Linux a eu lieu la semaine dernière à Ottawa, au Canada.
Tout d'abord, le lundi 17 et le mardi 18 juillet avait lieu le Kernel Summit, une réunion réservée à une centaine de développeurs du noyau dûment invités. Jonathan Corbet, principal auteur du site Linux Weekly News, était présent et relate la teneur des discussions dans un compte-rendu très riche. Il y a donc été question de sécurité, de temps réel, des interfaces du noyau, de la virtualisation, du VFS, de la scalabilité, du processus de développement du noyau et de la qualité et de bien d'autres sujets encore.

la suite dans le corps de l'article...
Suite à ce Kernel Summit a eu lieu, de mercredi à samedi, le Linux Symposium, une conférence plus traditionnelle, ouverte à tous malgré le prix un peu élevé. Comme le programme l'atteste, les sujets abordés lors des conférences, ateliers et sessions de réflexions étaient divers et passionnants. Ceux qui n'ont pas eu la chance de s'y rendre peuvent par exemple consulter les actes (volume 1, volume 2), ou encore les comptes-rendus journaliers proposés par NewsForge (jour 1, jour 2, jour 3, jour 4). À nouveau, Jonathan Corbet a publié le compte-rendu de quelques conférences, en particulier une conférence de Dave Airlie sur les pilotes graphiques libres (slides), une conférence de Dave Jones intitulée On how userspace sucks et une conférence d'Ulrich Drepper concernant une nouvelle API pour la communication réseau.

De plus, comme tous les ans, Jonathan Corbet a ouvert le Linux Symposium par sa traditionnelle conférence The Kernel Report, dont les slides sont disponibles. Il fait le tour de l'état actuel du noyau et tente de faire quelques prédictions sur l'avenir proche du développement. On pourra lire également avec intérêt les slides de la conférence sur GIT, donné par son mainteneur, Junio C. Hamano qui constitue une bonne introduction aux concepts de GIT. Enfin, la keynote qui clôture traditionnellement le Linux Symposium a cette année été animée par une conférence de Greg Kroah Hartmann, et les slides de celles-ci, accompagnées de leurs notes, laissent supposer que le moment devait être à la fois passionnant et sympathique.

Pour terminer, Linux Weekly News publiera vraisemblablement ce jeudi un résumé plus complet de cette rencontre, dans sa section consacrée au noyau. Les articles sont disponibles immédiatement sur abonnement, ou bien une semaine après leur publication.

Aller plus loin

  • # Pour le prochain Kernel Summit

    Posté par (page perso) . Évalué à 9.

    Lorsque j'ai conçu les RMLL, c'est ce type de réunion que je visais en priorité ainsi que les rencontres entre projets voisins ou concurrents. Je souhaite que les conférences, dont le nombre a atteint 300 cette année ne soient qu'un complément aux ateliers. C'est en faisant attention à conserver cette ligne de conduite que les RMLL dureront.

    Je fais donc un appel à tous ceux qui participent à un projet pour utiliser l'infrastructure des RMLL pour en réunir les acteurs. En 2007, ce sera à Amiens et il est temps, dès maintenant de lancer les invitations.
    J'espère qu'un développeur du noyau saura inviter le Kernel summit aux RMLL.
  • # Sommet Linux 2006

    Posté par (page perso) . Évalué à 10.

    Bor*el de m*rde !

    Alors comme ça on profite lâchement du fait que je doive gagner ma croute en allant bosser pour poster dans mon dos une news sur le sommet Linux ?
    Bon tant pis, il est hors de question que ce soit uniquement dev/null qui profite de mes petits résumés amoureusement fignolés....
    Je poste donc MA news ;-)



    Comme l'an dernier le site Linux Weekly News vient de rendre disponible son compte rendu complet du sommet 2006 des développeurs du noyau Linux qui a eu lieu les 17 et 18 juillet à Ottawa.
    Cette réunion des principaux developpeurs du noyau est conçue pour permettre de décider les futures orientations technique de Linux et pour présenter les divers travaux en cours.
    Comme en 2005 une Photo de groupe est disponible. Elle démontre une augmentation vertigineuse du nombre de femmes dans l'assistance (+100% !).


    Journée du 17 juillet


    Conférence sur les processeurs

    AMD a annoncé l'arrivé de multiprocesseurs ayant des coeurs tournant chacun à des vitesses variables afin de réduite la consommation d'énergie. La firme de processeurs embarqués Freescale désire que le noyau puisse autoriser les opérations cryptographiques asynchroneset supporte les accélérations hardware des fonctions réseau.
    Les developpeurs ont également évoqués les risques d'erreurs aléatoires au fur et à mesure que les transistors deviennent plus petits. Le noyau devrait permettre de confiner ces erreurs et de tuer la tâche fautive au lieu de se mettre en panic.
    Enfin les fonctions de préchargement de données présentes dans des processeurs deviennent de plus en plus complexes et efficaces et les développeurs réfléchissent au fait que le code noyau s'occupant explicitement de ce préchargement va sans doute devenir moins utile ou même néfaste.

    Multi-Conférence sur divers sujets

    Cette session a abordé plusieurs mini-sujets de façon rapide : l'inclusion de la pile wifi DeviceStack qui se passe bien mais qui n'est pas encore apte au support des machines SMP; Le support de la qualité de service pour les réseaux sans fil; Les risques légaux en cas de reverse-engineering; les problèmes de fragmentation de mémoire; l'arrivée d'une infrastructure de tests pour la compatibilité ACPI. Le dernier sujet était la consommation de la batterie sous Linux et sous Windows. L'OS de Redmond est capable de tenir 290 minutes alors que Linux stoppe après 240 minutes. Il semble que Windows fasse une lecture en avance (readahead) du disque afin de remplir des tampons et stopper le disque plus vite. Des progrès du noyau sont donc à attendre de ce coté.

    Conférence sur la qualité du noyau et le processus de developpement

    Andrew Morton a présenté les résultats de son sondage informel auprès des lecteurs de LWN au sujet de la qualité du noyau. Une des plaintes courantes des utilisateurs est que le fait de rapporter un problème sur le bugzilla du noyau ne conduit à aucune réaction des developpeurs. La décision a été prise que les bugs postés sur le bugzilla du kernel seront automatiquements postés sur les kernel mailing-lists correspondantes.
    Il a également été pointé le fait que beaucoup de personnes écrivent du code noyau mais que peu d'entre elles se consacrent à la relecture des patches des autres developpeurs. C'est ce qui explique, en partie, la longue attente de Reiser4 dans la branche -mm du fait de l'absence de volontaires pour la relecture et la validation du code.

    Conférence sur l'interface ioctl()

    Cette conférence très technique s'est concentrée sur la meilleure façon de gérer les interfaces avec le code noyau. L'interface ioctl() est une des techniques pour ajouter des appels système mais elle pose de nombreux problèmes : Les nouveaux appels système introduits tendent à êtres différents pour chaque périphérique; l'API résultante n'est pas revue; l'interface pose des problèmes sur les systèmes mixtes 32/64 bits et enfin la compatibilité avec les outils comme strace est médiocre. Des solutions pour contourner ces problèmes ainsi que des alternatives à ioctl() ont été discutés.


    Conférence sur l'ABI du noyau (Application Binary Interface

    Cette ABI, qui reste stable de manière à ce que les applications en user-space continuent de fonctionner après un changement de noyau, devient difficile à maintenir avec le temps. Une solution est d'utiliser Sysfs qui fait le lien entre l'ABI vue par les applications et l'API interne du noyau (susceptible de changer en permanence).
    Le sujet de la capture des logs de crash du noyau avec le programme HAL (infrastructure d'abstraction du matériel qui est soutenue par Freedesktop et est commune à KDE et Gnome) a été évoqué. Pour améliorer la qualité de HAL une solution serait d'éventuellement l'inclure dans l'arbre des sources du noyau.


    Conférence sur la mise en veille (Software suspend)

    La controverse a été vive entre les partisans de la solution inlcuse dans le noyau et ceux en faveur d'un programme en espace utilisateur (ce qui permet d'avoir facilement des fonctions de compression et de chiffrage). Aucun consensus clair n'a pu surgir sur l'inclusion ou non des patches suspend2 de Nigel Cunningham. Ce sujet est difficile et Linux reste très en retard par rapport aux OS propriétaires ce qui provoque la grogne des utilisateurs.

    Conférence sur la documentation

    Cette conférence, co-dirigée par l'éditeur de LWN Jonathan Corbet, a pointé du doigt l'absence de maintenance de la documentation du noyau. On peut trouver dans cette documentation des phrases évoquant le fonctionnement de binaires Java avec le kernel 1.3 (!) ou d'autres détaillant comment faire marcher Linux sur des machines exotiques ayant plus de 16 Mo de RAM (!). Des discussions au sujet des outils de documentation automatique du code sont arrivées à la conclusion qu'il est actuellement trop lent d'utiliser ces techniques.
    Les man pages sont également en retard (celle sur le réseau se réfère au noyau 2.2). Une solution serait qu'un mainteneur à plein temps soit payé pour s'occuper de ces man pages. La solution (adoptée par OpenBSD) d'imposer que chaque patch d'un developpeur soit accompagné d'une mise à jour de la man page correspondante a été refusée par Linus Torvalds. Selon lui ce n'est pas une bonne solution du fait que les developpeurs du noyau ne savent pas écrire de la documentation utile (a lot of kernel developers have huge problems communicating with humans).



    Journée du 18 juillet


    Conférence sur les patches pour le temps réel

    L'inclusion du patch implémentant le support du temps réel a été évoqué par les developpeurs présents à cette conférence. Ce patch s'est réduit en taille ces derniers mois (il ne fait plus que 700 Ko) du fait de l'inclusion progressive dans le noyau de diverses fonctions liées au temps réel (futexes robustes, priority inheritance, couche IRQ générique, lock validator).
    Les avancées futures concerneront les entrées/sorties temps réel pour les disques et les systèmes de fichiers.


    Conférence sur les systèmes embarqués

    Un des problème qui a surgit lors du developpement du projet OLPC (One Laptop Per Child) est celui des systèmes de fichiers spécifiques pour les mémoires flash. Le projet JFFFS2 n'a pas été prévu pour des grandes tailles de mémoire flash et il est nécessaire d'avoir du neuf dans ce domaine. En ce qui concerne le temps de boot du kernel (un problème crucial dans le monde de l'embarqué) il semble que les choses empirent et qu'une nouvelle approche doive être envisagée. On pourrait par exemple tester en paralèlle les périphériques lors du boot au lieu de le faire séquentiellement. Néanmoins il existe un risque de conflit de priorité (race condition). Des efforts importants pour réduire la taille du noyau (dans le cas de l'architecture i386) ont permis d'aboutir à des progrès significatifs : élimination des fonctions inline non indispensables; remplacement des sous-systèmes par des technologies plus légères (SLOB Allocator) suffisantes pour l'embarqué.

    Conférence sur la sécurité

    La conférence sur la sécurité, très attendue du fait de la controverse persistante entre les partisans de SELinux et les tenants d'AppArmor, a examiné ces deux technologies ainsi que la question du maintien ou non de la couche d'abstraction des modules de sécurité (LSM). Les developpeurs de SELinux ont critiqué le fait qu'AppArmor se base sur les noms de chemins (pathname) ce qui, selon eux, est dangereux car non déterministe. La discussion a été âpre mais il semble qu'AppArmor va être autorisé à entrer dans le noyau mainline ce qui assure également la perennité de LSM).

    Conférence sur la virtualisation

    Xen a été évoqué et il représente la seule solution libre de paravirtualisation disponible actuellement. L'inclusion dans le kernel progresse normalement. Néanmoins les développeurs souhaitent un peu de variété est ils ne veulent pas que Xen soit l'unique candidat. Une solution est de placer des points d'entrée génériques (hooks) dans le noyau afin que différents hyperviseurs puissent s'accrocher au kernel. Il y a toutefois le risque de graver trop tôt l'interface générique dans le marbre avant que les technologies de virtualisation soient vraiment matures.
    L'option des containers a été examiné également dans le détail avec tous les problèmes d'espace de noms (namespace) qui apparaissent dans ce cas. Il faut arriver à ce que chaque container aie son espace de noms privé afin d'éviter les interférences. Le risque que les auteurs de rootkits utilisent ces containers a été évoqué sans qu'une solition claire n'émerge.

    Conférence sur les procédures automatiques de test

    Cette session n'a pas été très conflictuelle car tous le monde souhaite plus de tests afin de détecter les bugs le plus vite possible. Une procédure automatisée a été mise en place pour tester les versions du kernel et pour identifier les patchs fautifs. Les résultats sont disponibles sur cette page.

    Conférence sur la couche VFS (Virtual File System)

    Le code de la couche VFS n'a pas évolué significativement depuis quelques années ce qui tend à prouver sa maturité. De nouvelles fonctions sont néanmoins à l'horizon comme la possibilité pour les simples utilisateurs de monter les systèmes de fichier; le démontage même si un processus est resté ouvert; le montage à des emplacements différents et avec des attibuts différents ou encore l'idée d'Unionfs qui fusionne plusieurs systèmes de fichiers afin de présenter une vue représentant leur aggrégation.

    Conférence sur la scalabilité

    Les discussions sur ce sujet ont évoqués les limites qui apparaissent au fur et à mesure que le nombre de processeur du système augmente. Actuellement Linux fonctionne sur des machine NUMA à 1024 noeuds (4096 processeurs) mais le temps de boot est de plus d'une heure du fait qu'un seul processeur est chargé de l'initialisation. Il va être nécessaire de parcelliser cette fonction afin de la répartir sur plusieurs processeurs. De façon générale cette recherche des limites de Linux améliore réguliérement la qualité des algorithmes employés et est très bénéfique pour le kernel.

    Conférence sur les problèmes de DMA et IOMMU

    Encore une conférence extêmement technique sur la virtualisation des unitées de gestion mémoire des entrées/sorties (I/O memory management units). Cette virtualisation semble poser des problèmes de sécurité. En effet si un périphérique possède des droits d'écriture sur la mémoire (Direct Memory Access) alors il va pouvoir interférer avec tous les autres périphériques du système. Les choses devienent ancore plus compliquées si on tente de partager ces périphériques entre plusieurs machines virtuelles au point que personne ne voit vraiment comment faire cela de manière sécurisé.


    Conférence sur le processus de developpement (seconde conférence)

    La conférence de fermeture est revenue sur le processus de développement du kernel qui, selon Linus, fonctionne bien. Les points qui restent à améliorer concernent la branche -mm qui accueille des patches pour des durées trop longues; le manque de relecture critique par les pairs des patchs soumis et les relations avec les distributions qui peuvent s'avérer difficiles. Néanmoins Linus pense que les gens sont contents de l'état actuel du noyau (people are happy) ce qui a permis d'écourter la conférence et d'aller écluser plus vite les bières du bar.
    • [^] # Re: Sommet Linux 2006

      Posté par (page perso) . Évalué à 6.

      ça faisait plus d'une journée qu'elle était dans la file :p (nous attendions la dispo des liens lwn pour tous).

      si tu acceptais d'être relecteur, tu l'aurais vu passer ;-)
      Merci de tes compléments qui éviteront à certains de devoir déchiffrer l'anglais.
      • [^] # Re: Sommet Linux 2006

        Posté par (page perso) . Évalué à 1.

        Tu peux détailler un peu les contraintes du fait d'être relecteur ? c'est compatible avec des horaires de boulot ? On est mal vu des autres relecteurs si on n'exerce ce sacerdoce qu'épisodiquement ?
        • [^] # Re: Sommet Linux 2006

          Posté par (page perso) . Évalué à 4.

          Le fait d'être relecteur n'est pas très contraignant. Ce serait plutôt une sinécure si parfois, on ne tombait pas sur des articles dont le fond est très intéressant mais la forme (orthographe, grammaire et construction de l'article) sont bâclés et laissent à désirer. On ne sait alors si il vaut mieux voter contre, arranger l'article (mais ce n'est plus celui de son auteur) ou en faire un autre.
          Vu la qualité de ta rédaction, je suis d'accord avec Baud et je t'invite à te joindre à nous.
        • [^] # Re: Sommet Linux 2006

          Posté par (page perso) . Évalué à 2.

          Chacun s'investit comme il peut, il n'y a pas vraiment de contrainte, hormis que lorsqu'on vote contre une dépêche, il faut donner une raison qui tienne la route (bon pour certaines dépêches ce n'est pas très difficile :/).
          En terme de boulot, j et moi avons un peu tendance à remanier et wikipédifier systématiquement, parfois ajouter quelques paragraphes explicatifs.
          Certains ne font que voter ou s'assurer de l'orthographe et des liens, ou donner un complément dans la tribune d'admin'.

          Le seul truc, c'est que si tu commences à éditer, il faut terminer suffisamment rapidement pour ne pas bloquer la dépêche indéfiniment...

          Pour la compatibilité avec des horaires de boulot, je ne comprends pas trop : c'est pas comme si on y passait tout l'après-midi non plus :p, trouver une petite demi-heure le midi ça le fait...

          En tout cas, il ne faudrait pas que ça freine ton élan à soumettre des dépêches ou des journaux intéressants ;-)
        • [^] # Re: Sommet Linux 2006

          Posté par (page perso) . Évalué à 1.

          Cf https://linuxfr.org/moderateurs/

          T'es pas obligé de relire pendant tes horaires de boulot (et sinon c'est pas forcément très long de relire une dépêche, on a pas à les re-rédiger complètement à chaque fois heureusement :).
          Concernant l'activité du relecteur, je regarde épisodiquement les stats qui indique « machin (XX éditions, XX avis) » (calculé sur 30j) et si les chiffres sont à 0, c'est que tu n'as plus le temps d'être relecteur en gros :).
          • [^] # Re: Sommet Linux 2006

            Posté par (page perso) . Évalué à 2.

            Ok j'ai cliqué sur le petit bouton d'acceptation.
            Maintenant il faut que je m'y retrouve dans l'interface pour donner son avis. Je vais sans doute faire quelques conneries avant que je comprenne comment ça marche....ça a toujours été ma méthode.
    • [^] # Re: Sommet Linux 2006

      Posté par . Évalué à 2.

      L'article du point de vue temps réel n'est pas top.

      Comment dire que linux assure du 20 µs de latence quand certain drivers peuvent prendre la main pour des millisecondes.

      Pour qu' un système sois temps réel, il faut _aussi_ que les drivers soient prévus avec une latence maximum faible, le soft dispose bien d'entrée-sortie sinon il ne sert à rien...

      "La première sécurité est la liberté"

      • [^] # Re: Sommet Linux 2006

        Posté par (page perso) . Évalué à 3.

        Peut-être que pour la majorité des drivers, il n 'y a pas de problème... sinon effectivement c'est plus vraiment du temps-réel garanti!

        Sinon, par-rapport à l'approche double noyau (RTLinux, RTAI) que je connais (relativement lourde avec les échanges à gérer entre les mondes RT/Linux) et qui date depuis un certain temps maintenant, visiblement les choses ont pas mal évolué.
        Si j'ai bien compris, avec xenomai (et même RTAI nouvelle génération, il me semble?) il est dorénavant possible d'avoir des threads tournant dans l'espace utilisateur en temps-réel.

        Et maintenant, Linux patché, directement qui peux faire du temps-réel...

        Bon, finalement, quel est le système à utiliser aujourd'hui, voir demain ?

        Quelqu'un ici qui a déjà utilisé ces nouveaux systèmes ?

        A+
        • [^] # Re: Sommet Linux 2006

          Posté par . Évalué à 2.

          les temps mini diminuent encore mais le principe même est d'utiliser les drivers linux, ou de les réécrires soi même...

          "La première sécurité est la liberté"

  • # Sympta les proceedings

    Posté par . Évalué à 2.

    Il y en a qui sont tres sympa a lire: "why userspace suck" qui donne bien un debut d'explication pourquoi Linux boote deux fois plus lentement qu'un BeOS..

    Je n'ai pas encore tout lu, mais j'ai bien aimé aussi "The Need for Asynchronous, Zero-Copy Network I/O".
  • # bonne nouvelle !

    Posté par (page perso) . Évalué à 2.

    Eh oui... si comme moi tu ne comprends rien au fonctionnement du kernel, il te reste .... tatatatatattatatatat... (<----- bruit du roulement de tambour).....
    La photo de groupe du Kernel Summit !!!!!

    C'est le Happening de l'année ! :D


    ok... je sors....

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.