L'augmentation continue de la puissance de calcul, des fonctionnalités présentes et des empreintes mémoires (RAM, FLASH, ROM...) des processeurs 32 bits tend à créer une classe de processeurs hybrides :

• ils sont suffisamment puissants pour exécuter des tâches complexes (réseau, affichage...) ;
• ils sont trop petits pour faire fonctionner de façon raisonnable les systèmes d'exploitation Open Source classiques (GNU/Linux, Android, *BSD...).

Les architectures Cortex-M3 et Cortex-M4 d'ARM rentrent clairement dans cette catégorie.

Même si il existe un portage de uClinux sur STM32 (ici et là), il est indispensable de posséder une mémoire externe de plusieurs dizaines de mégaoctets (mémoire interne de l'ordre de centaines de Kio).

Dans cette optique nous avons décidé de publier le code source de Lepton/Tauon sous licence MPL/EPL (au moment de cette rédaction il s'agit de la MPL 1.1).

Lepton/Tauon est un système d'exploitation temps réel (RTOS, pour Real Time Operating System) qui tente de respecter au maximum le standard POSIX (« POSIX compliant ») tout en gardant à l'esprit les contraintes :

• d'empreinte mémoire ;
• de fiabilité ;
• de simplicité ;
• de portabilité.

Le micrologiciel (firmware) généré se présente sous la forme d'un ELF contenant :

• le noyau ;
• les pilotes de périphériques ;
• les bibliothèques ;
• les pseudo-binaires systèmes et utilisateurs.

Linus Torvalds, dictateur bienveillant et grand protecteur du noyau Linux, envisage de mettre à disposition le noyau 2.6.40 sous la dénomination 2.8.0, voire 3.0, comme suggéré par Ingo Molnar.

Depuis la sortie du noyau 2.6.0 en décembre 2003, nous avons pu assister à l’évolution de notre noyau spheniscidé tout au long de ses 40 versions successives. Toute cette évolution s’est faite en suivant un protocole bien rodé, comprenant des cycles de développement de 8 à 12 semaines.

Le cycle de développement commence avec la mise à disposition d’un noyau stable numéroté 2.6.x, suivi d’une fenêtre d’intégration de deux semaines. Cette fenêtre est l’occasion pour les développeurs de proposer tous les patches introduisant de nouvelles fonctionnalités aux différents mainteneurs du noyau.

Ensuite commence la longue route de la stabilisation. Au gré des messages attendus et parfois redoutés de ce pragmatique néo‐Américain qu’est Linus Torvalds, nous voyons apparaître environ 8 versions candidate (RC). À ce stade du développement, n’essayez pas d’introduire la moindre petite fonctionnalité ou le moindre petit pilote, ou il vous en cuira, et chacun pourra suivre sur la liste de diffusion du noyau Linux (LKML) votre admonestation par le sieur Torvalds.

Enfin, lorsque la RC semble suffisamment stable, Linus Torvalds lâche le noyau 2.6.(x + 1) dans la nature, et un nouveau cycle peut recommencer.

Mais cette fois, quelque chose de différent risque d’arriver : le nouveau noyau passera à la version 2.8 ou 3.0 ! Concrètement, quelle est la raison de ce changement de numérotation ? Quelles nouvelles fonctionnalités révolutionnaires, quel changement d’API et quelle grande réécriture du code entraîne ce passage à une version 2.8 ? Rien. Linus nous fait juste savoir dans un post scriptum, que des voix dans sa tête lui ont dit que 40, c’est grand, et donc qu’il faut passer à une version supérieure.

Néanmoins, il ne faut pas s’y tromper. Le mode de développement du noyau, qui se fait de manière progressive, pas après pas, a engendré des changements énormes depuis la 2.6.0. Donc, même si ce noyau s’inscrira dans la continuité du 2.6.39, ça permettra sans doute aussi de satisfaire notre besoin de discriminer de grandes étapes du développement linuxien, et de pouvoir s’asseoir devant son PC d’ici quelques mois en se disant « Ouah, j’utilise la nouvelle génération de noyaux Linux ! ». Et rien que ça ravira les geeks du monde entier au plus profond de leur cerveau reptilien.

À chaque fois que je lis les dépêches LinuxFr.org sur le nouveau noyau ou bien les nouvelles de Phoronix, je m’empresse de regarder les avancées des pilotes graphique libres. Et souvent, je vais sur la page Mesa traçant les évolutions de l’implémentation d’OpenGL. Mais je trouve difficile de suivre où en est réellement la progression de cette adaptation dans Mesa et de ses différents pilotes graphiques qui en dépendent. C’est pourquoi j’ai décidé de faire un script qui parcourt ce fichier et l’affiche de manière plus intelligible.

 http://mesamatrix.net/

Si vous adorez suivre la course qui se tient entre Mesa et OpenGL, et que vous allez souvent voir quelles sont les nouvelles extensions OpenGL qui ont été implémentées et pour quels pilotes, ça pourrait vous intéresser ! Plus d’explications dans la suite de la dépêche.

Greg Kroah-Hartman est le mainteneur de la branche -stable du noyau Linux. Dans son annonce du 2.6.32.58, il a indiqué qu'il passait la main à Willy Tarreau pour veiller sur cette branche 2.6.32 et il vient de publier une rétrospective très intéressante à propos de ce noyau.

NdM : merci à patrick_g pour son journal.

Depuis l'arrivée de l'ordonnanceur de processus CFS dans le noyau Linux (2.6.23) et la généralisation des processeurs multi-coeurs, plusieurs projets cherchent à améliorer la réactivité du noyau Linux, notamment pour un environnement bureau. En septembre 2009, Con Kolivas a écrit un nouvel ordonnanceur appelé BFS (Brain Fuck Scheduler). En le comparant à CFS, des bugs ont été isolés puis corrigés dans CFS. Par exemple, un test avec le codec x264 a montré que BFS était 80% plus rapide : le bug a été isolé puis corrigé par Mike Galbraith (lire Open source collaboration done right). Depuis, Con Kolivas continue d'écrire des patchs pour améliorer la réactivité.

Plus récemment, ce même Mike Galbraith a proposé un patch sur la LKML le 19 octobre 2010 pour regrouper automatiquement les tâches par terminal (TTY). Suite aux critiques d'autres développeurs, il a écrit une deuxième, puis une troisième version de son patch. Linus en personne s'est réjoui qu'un si petit patch, non intrusif, soit capable d'améliorer autant l'interactivité. Le lendemain, un article paru sur Phoronix montre en vidéo le gain notable en utilisant un cas de test similaire à celui de Linus : lancer une compilation du noyau avec make -j64 (lance 64 tâches de compilation en parallèle) dans un terminal, tout en utilisant un bureau : navigateur web et lecture de vidéo en HD.

Le patch améliore l'interactivité en distribuant le temps de processeur plus équitablement du point de vue de l'utilisateur. Il utilise les cgroups (groupe de tâches) introduits dans le noyau 2.6.24 (janvier 2008) pour l'ordonnanceur CFS. CFS permet de définir le pourcentage de temps assigné à un cgroup. Cette fonctionnalité révolutionnaire a été un peu oubliée car la création des cgroup était manuelle. Le patch de Mike propose de créer automatiquement un cgroup par TTY, et permet donc de mettre en application simplement le travail sur CFS et les cgroups. Con Kolivas a néanmoins critiqué le patch sur son blog en expliquant qu'il introduit des régressions dans les cas d'utilisation « normaux ».

Proposé après la fenêtre de tir du noyau 2.6.37, l'avenir nous dira si ce patch va être intégré ou non dans le noyau 2.6.38. Plus généralement, ces différents projets devraient à terme améliorer la réactivité de nos environnements de bureaux sous Linux.

NdM : Merci à Poloh d'avoir proposé une dépêche sur le même sujet et insert_coincoin pour son journal en lien ci-dessous.

Btrfs est un système de fichier transactionnel de type 'Btrfs sur nos postes de travail.

Un nouveau root exploit est apparu mardi et concerne les noyaux Linux de 2.6.38 à 3.8.8 ayant CONFIG_PERF_EVENTS activé.

Tapez la commande suivante pour savoir si vous êtes impacté :
zgrep CONFIG_PERF_EVENTS /proc/config.gz

Si zgrep répond cette ligne, vous êtes impacté.
CONFIG_PERF_EVENTS=y

Le patch existe depuis plusieurs semaines mais n'a pas été forcement intégré dans toutes les distributions - cherchez le code CVE-2013-2094 dans les derniers security advisory.

La Debian Wheezy a été patchée ce matin (je mets le lien vers le mail de la liste de diffusion « security » car je ne trouve pas l'annonce de sécurité debian sur le site).

Pour ceux qui ne peuvent pas patcher immédiatement leur noyau, il faut suivre le lien vers l'outil de suivi de bug de redhat qui propose plusieurs solutions temporaires plus ou moins efficaces.

Microsoft ♥ Linux et comme « Il n’y a pas d’amour, il n’y a que des preuves d’amour », treize ans après son apparition, Microsoft souhaite encourager l’inclusion de son système de fichiers exFAT dans le noyau Linux, en ouvrant les spécifications de ce dernier.

Quelques semaines après cette annonce, qu’en est‐il vraiment ?

Plus de deux ans après sa sortie et sa nouvelle numérotation qui a beaucoup fait parler d'elle, le noyau 3.0.x ne sera plus mis à jour. La série 3.0.x était une version supportée sur le long terme (LTS - Long Term Support). Greg Kroah-Hartman incite à basculer sur les autres LTS qu'il maintient, soit la branche la plus récente, à savoir la 3.10.x ou à défaut 3.4.x, sachant que cette dernière sera maintenue encore un an. Si vous utilisez directement les noyaux de vos distributions, vous n'êtes que peu concerné(e). Par contre, si vous gérez vous même votre propre noyau, il est temps de basculer !

L'annonce de fin de vie a été faite le 13 octobre dernier lors de la sortie du 3.0.100, rappelée régulièrement (notamment lors de la stable review du 3.0.101 et actée lors de la sortie finale du 3.0.101 :

This is the LAST 3.0.x longterm kernel release.

It is now end-of-life.

I will NOT be doing any more 3.0.x kernel releases. If you rely on the 3.0.x kernel series, you should now move to the 3.10.x kernel series, or, at the worse case, 3.4.x. Note, 3.4.x will only be maintained for one more year, so your time is limited on that as well.

Hardware Detection Tool est un outil de bas niveau permettant l’identification du matériel cible sur le matériel cible : extraire les informations, vérifier la conformité, valider ce matériel, voire anticiper les besoins d’installations et mettre en œuvre les processus adéquats.

Cette nouvelle version, sortie aujourd’hui, ajoute la possibilité d’extraction et d’envoi du rapport par le réseau.

Voici un projet qui vient de voir sa toute première version : kconfig-frontends est un empaquetage propre du langage kconfig, utilisé par le noyau Linux.
kconfig-frontends est maintenant disponible en version 3.3.0-0 !

Plus de détails dans la suite de la dépêche.

NdM : merci à ymorin pour son journal.

Avec toute l’agitation et la parution rapide des correctifs au sujet des failles Meltdown et Spectre, il peut être difficile de savoir si son processeur est affecté et quel est le niveau exact de protection de sa machine.
Afin d’aider les utilisateurs à trouver l’information, le développeur Thomas Gleixner a introduit un nouveau mécanisme qui permet d’avoir une vue unifiée de l’état actuel de son noyau.

Dans le cadre des entretiens de LinuxFr.org, nous avons contacté Willy Tarreau pour un entretien. Il a eu la gentillesse de répondre aux 10 questions que nous avions sélectionnées parmi les propositions des lecteurs de LinuxFr.org.

Vous pouvez lire cet entretien dans la seconde partie de cette dépêche. Il est placé sous triple licence : GNU Free Documentation License (sans section invariante), Art Libre et Creative Commons By-Sa.

Pour ceux qui ne le connaissent pas, rappelons que Willy Tarreau est un contributeur de longue date du noyau Linux. Sa branche hotfix a connu un certain succès et depuis 2005, il est le mainteneur officiel de la branche 2.4 du noyau Linux. Il participe également au développement de la branche 2.6.

En dehors du noyau Linux, il est le développeur du répartiteur de charge HAProxy, a écrit un certain nombre d'outils pour faire des tests d'injection réseau et a créé sa distribution, Formilux, avec un ami.

hupstream est fier de vous annoncer la 3^e édition de Kernel Recipes, les 25 et 26 septembre 2014.

Cette nouvelle édition s’annonce pleine de promesses. Cette année nous vous proposons des conférenciers venus des États‐Unis, d’Europe et de France : Greg Kroah‐Hartman, Hans Peter Anvin, Jean Delvare, Willy Tarreau, Borislav Petkov, Martin Peres, Maxime Ripard, Julien Grall, Eric Leblond, Samir Bellabes et Hans Verkuil.

Nombre d’entre eux interviendront pour la première fois en France.

La 4^e édition de Kernel Recipes a eu lieu 30 septembre au 2 octobre à Paris, dans les locaux de Mozilla.

Cette édition a rassemblé pas loin d'une vingtaine d'intervenants, et une centaine de participants ont assisté aux 3 jours de conférence. Cette année encore les journées furent riches en échanges et discussions, ponctués par les dessins de Frank Tizzoni. Cette édition fut l'occasion d'assister à une publication en direct du noyau stable, la 3.14.54, dénommée "Kernel Recipes".

La tradition du kernel diner a été respectée et a permis à une cinquantaine de convives de poursuivre ces discussions.

Avec un peu de retard, l'ensemble des vidéos, supports et photos est maintenant en ligne et librement accessible. Un grand merci à l'équipe de Mozilla Paris qui s'est rendue disponible pendant ces 3 jours pour réaliser la captation vidéo, et spécialement Sylvestre Ledru. Merci de nous permettre de diffuser ces supports pour tous ceux qui n'ont pas pu se déplacer.

Nous souhaitons remercier encore une fois les intervenants qui ont contribué à la réussite de cette édition et également nos sponsors : Gandi, BayLibre, HaProxy Technologies, Mozilla, Parrot, SUSE

Rendez-vous pour la 5^e édition, en septembre 2016 !

La sixième édition de Kernel Recipes s’est terminée et, après quelques jours de repos, les supports de présentation sont disponibles en ligne.

Plus de 130 participants sur trois jours, une vingtaine de conférences, des lightning talks sur une grande variété de sujets et des intervenants venus du monde entier.

Après le succès de la première édition, la deuxième édition de Kernel Recipes aura lieu les mardi 24 et mercredi 25 septembre 2013, au Carrefour Numérique de La Villette, à Paris (métro Porte de la Villette).

Cette fois-ci, ce sont deux jours de conférences entièrement consacrées au noyau Linux, et ce, sur demande des participants de la première édition. L'objectif de ces journées reste de mettre en contact ceux qui font le noyau par leurs contributions et ceux qui l'utilisent de manière plus ou moins avancée, et favoriser ainsi les échanges et discussions.

Au programme de cette édition, une douzaine de conférences sur des thèmes variés : la sécurité, le support de l'architecture ARM, les outils de debug du noyau, les nouveautés…

Les conférences seront filmées et diffusées par la suite.

Pour y assister c'est très simple, il suffit de vous inscrire sur le site. Vous pouvez également venir présenter votre sujet favori au cours des lightning talks réservés aux participants.

Cette septième édition a donné lieu une fois de plus à de nombreux échanges passionnants entre participants et avec les orateurs. Plus d’une vingtaine d’interventions en trois jours et depuis sept ans, 300 l de café, 20 kg de fromage, quelques litres de sueurs provenant des organisateurs et des orateurs et surtout beaucoup d’interventions talentueuses.

L’ensemble des vidéos et présentations de cette édition est maintenant disponible en ligne.

Brad Spengler a décidé de faire parler de lui cette année :-) Il a écrit le 16 septembre dernier un exploit pour le noyau 2.6.31 tout chaud, à peine sorti du four (le 9 septembre). Il a d'abord posté des vidéos sur Youtube puis, le 18 septembre, le code de son exploit.

La faille se situe dans perf_counter, fonctionnalité introduite dans Linux 2.6.31. Elle n'impacte donc que cette version. La faille a été corrigée le 15 septembre (perf_counter: Fix buffer overflow in perf_copy_attr()), la veille de la première vidéo.

Malgré les corrections apportées à SELinux (ex: Security/SELinux: seperate lsm specific mmap_min_addr), cet exploit arrive à contourner SELinux en utilisant, encore une fois, le mode unconfined_t. Ce mode est utilisé pour les applications ne pouvant pas être confinées dans SELinux, comme par exemple WINE.

Kernel Recipes aura lieu le vendredi 21 septembre 2012, de 9h30 à 18h40, au Carrefour Numérique de la Cité des Sciences de La Villette, à Paris.

Kernel Recipes est la première journée de conférences dédiée au noyau Linux. La journée se veut un moment privilégié pour échanger avec ceux qui font le noyau au quotidien, ceux qui l'utilisent dans des projets professionnels ou non.

Une journée de conférences et d'échanges, avec une possibilité pour les participants d'inscrire un projet, une réflexion aux lightning talks (conférences éclair).

Il est prévu de prolonger les discussions durant le déjeuner proposé sur place, ainsi que le soir pour ceux qui se joindront au dîner.

Pour y participer, merci de vous enregistrer.

Le Kernel Recipes 2016 est terminé, mais vous pouvez dès maintenant consulter les vidéos et les supports de cette cinquième édition.

Plus de 120 personnes ont fait le déplacement pour ces trois jours de conférences dédiés au noyau Linux. Une vingtaine de conférences ont eu lieu sur des sujets extrêmement variés. Merci à Anisse Astier qui a réussi le petit exploit de tenir un live blog durant l’événement.

C’est devenu presque une tradition. Avec la fin de l’été, hupstream est fier de vous présenter la septième édition de Kernel Recipes. Elle aura lieu à Paris du 27 au 29 septembre 2017.

Pour cette septième édition, nous avons tenté encore une fois de vous proposer une liste d’intervenants qui viendront du monde entier : Greg Kroah‐Hartman, Brendan Gregg, Benjamin Tissoires, Steven Rostedt, James Bottomley, Kees Cook, Andrea Arcangeli, Thomas Gleixner, Maxime Ripard, Johan Hovold, Sasha Levin, Werner Koch, Jens Axboe, Kevin Hilman, Hans Verkuil, Sjoerd Simons, Éric Leblond.

Après quatre années de développement, SystemTap annonce fièrement sa version 1.0 (le 23 septembre).
Pour rappel, SystemTap est un outil permettant d'analyser le fonctionnement d'un noyau Linux en cours de fonctionnement, à la manière de DTrace. Il s'utilise en ligne de commande avec un langage de script qui lui est dédié.
Le projet est distribué sous licence GPL et développé par Red Hat, IBM, Intel, Hitachi et Oracle. Vous trouverez de nombreux exemples sur le site Internet.

Le 19 août dernier, c'est Valgrind qui sortait sa version 3.5.
Valgrind contient plusieurs outils dont les plus connus sont memcheck (tracer les fuites mémoires et accès invalides à la mémoire) et Callgrind (tracer les appels de fonction et mesurer le temps d'exécution).
Mais, il existe d'autres outils comme Helgrind (analyser les erreurs liées aux processus légers), Cachegrind (analyser l'utilisation du cache et la prédiction des branches), Massif (profileur de la mémoire allouée sur le tas), etc.
La version 3.5 apporte notamment le support de Mac OS X en plus de Linux.

NdM : Merci à liberforce pour son journal sur la sortie de Valgrind 3.5

Kernel Recipes a eu lieu les 24 et 25 septembre 2013 au Carrefour Numérique de La Villette, à Paris. Cette deuxième édition est venue confirmer le succès du format proposé en 2012 : une rencontre entre ceux qui font le noyau Linux et ceux qui l’utilisent en entreprise, une rencontre à taille humaine dans un cadre convivial.

Les vidéos et les slides sont désormais disponibles en ligne.

La vieille blague de linuxfr.org IPOT prédisait que le noyau 3.2.24 ne serait plus publié au format bz2, rendant la décompression de l'archive impossible avec les moyens de 2001. Cela fait un moment que les noyaux sont publiés en tar.gz, tar.bz2 et tar.xz, on apprend maintenant que les prochaines versions du noyau seront publiées uniquement en tar.gz et tar.xz. La prochaine révision longterm 3.2.54 sera donc l'une des toutes premières affectées, la différence étant d'un seul caractère avec la prédiction d'IPOT.

Plus sérieusement, je me demande quelles options de compression seront utilisées. En effet dans le cas de la compression .xz, les besoins en mémoire augmentent considérablement pour les niveaux compressions les plus élevés (source man xz) :

(traduction) « L'utilisation de mémoire avec xz varie de quelques kilooctets à plusieurs gigaoctets, en fonction de paramètres de compressions. […] Le décompresseur aura typiquement besoin de 5% à 20% de la mémoire nécessaire au compresseur pour créer le fichier. […] Cependant, il arrive que des fichiers .xz requièrent plusieurs gigaoctets de mémoire pour être décompressés. »

(texte original) « The memory usage of xz varies from a few hundred kilobytes to several gigabytes depending on the compression settings. […] Typically the decompressor needs 5 % to 20 % of the amount of memory that the compressor needed when creating the file. […] Still, it is possible to have .xz files that require several gigabytes of memory to decompress. »

NdM : merci à JGO pour son journal.