Sortie officielle du noyau Linux 3.4

118
21
mai
2012
Noyau

La sortie de la version stable 3.4 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

PS. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction: laurent wandrebeck, detail_pratique, khalahan, _PhiX_, Damien Szczyt, Akiel et Benoît.

Sommaire

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 31 mars 2012 :

Ok, cela fait deux semaines et la période de merge est terminée. Linux 3.4-rc1 a été envoyé vers les serveurs git, et l'archive tar ainsi que les patches sont en cours d'envoi alors que je tape ceci (cela sera probablement terminé le temps que je finisse).
Et oui, si vous avez compté, cela ne fait que 13 jours. Et si certains attendaient le dernier jour pour envoyer leur demande de merge, je suis persuadé qu'ils seront vraiment ravis d'attendre deux mois supplémentaires jusqu'à la prochaine fenêtre d'intégration. Yay !

Cela dit, il y a encore quatre demandes de merge dans ma boîte mail qui sont en attente et que je vais (probablement) inclure, mais je voulais d'abord obtenir confirmation d'autres mainteneurs. Elles ont donc été envoyées dans les temps, j'ai juste décidé de faire le choix de leur intégration un peu plus tard.
Les quatre requêtes restantes (et les gens dont je veux des commentaires) sont :

- HSI (High Speed Synchronous Serial Interface). Je prévois de l'inclure dans le 3.4, c'est dans ma liste, mais je voulais que ça se sache au cas où quelqu'un aurait des problèmes avec cette dernière. Ping ?
- pohmelfs. Le vieux pohmelfs a été supprimé de staging ; il y en a un tout nouveau en attente sur le banc de touche. Al était un peu mécontent de certains aspects, Evgeniy en a corrigé certains, et la discussion s'est tarie. À nouveau, il y a des chances que je l'incorpore, mais je voulais davantage de commentaires à ce propos.
- La prise en charge préliminaire de drm dma-buf. Dave Airlie m'a envoyé la demande d'incorporation mais n'a pas beaucoup insisté, c'est dans ma catégorie « ok, je peux encore l'inclure pour 3.4 si les gens des pilotes DRM me disent que ça leur facilitera la vie. » C'est donc dans le flou — je n'ai rien contre, mais je ne l'inclurai pas à moins que quelques personnes me disent « oui, s'il te plaît. »
- Le framework DMA-mapping. Ce code a dorénavant quelques confirmations supplémentaires, et se trouve essentiellement dans la même situation que HSI : je l'incorporerai probablement, mais je voulais vraiment avoir l'avis des personnes concernées.

Et c'est tout. Il y a donc quatre demandes d'inclusion en attente, mais à part ça, c'est terminé (à moins que vous ne puissiez démontrer m'avoir envoyé un mail, mais qu'à cause d'une erreur cosmique — impliquant probablement mon incompétence — je l'ai manqué. Hé, ça arrive).
Quoi qu'il en soit, assez parlé de « ce qui reste en attente ». Si vous voulez savoir ce qui a été incorporé, une approche assez lisible est la suivante :

git log --merges --author=Torvalds v3.3..

Parce que j'ai vraiment essayé de faire des messages compréhensibles, avec des informations venant des sous-mainteneurs. Et beaucoup d'entre vous m'en ont envoyé, merci.
Un point important à signaler est que le nettoyage des fichiers d'en-têtes était un truc à faire, mais j'espère qu'on n'aura plus à le refaire. En tout cas, pas avant une version ou deux. Ce nettoyage a provoqué beaucoup de conflits de merge et quelques autres ennuis et, bien que je sois OK pour les résoudre, c'était suffisamment pénible pour que je ne veuille pas recommencer de sitôt. Je sais que des sous-mainteneurs ont eux aussi été embêtés et s'en sont plaint auprès de moi.
Cela dit, je pense que c'était utile. Le découpage de asm/system.h (et à plus petite échelle les nettoyages de bug.h) a peut-être été douloureux, mais les choses sont vraiment plus propres. Je devine donc que nous ferons à nouveau ce genre de chose dans le futur, mais je veux juste oublier à quel point c'est pénible d'ici à la prochaine fois. Ok ?

Dans tous les cas, merci de tester et rapporter toutes régressions.

RC-2

La seconde version candidate du noyau est sortie le 7 avril 2012 :

Une autre semaine, une autre -rc. Cela m'a semblé plutôt calme, mais à en croire les chiffres, c'est une -rc2 assez typique, peut-être même avec un peu plus de modifications qu'à l'accoutumée.

Cela dit, il n'a pas l'air d'y avoir beaucoup de choses effrayantes. Une bonne partie des changements sont des correctifs (que j'espère quasi-finaux) pour les modifications des fichiers d'en-têtes, ainsi que les trois demandes d'inclusion mentionnées dans l'annonce de la -rc1 : HSI (High Speed Synchronous Serial Interface, les bases de dma-buf, et ce qui concerne DMA mapping. Ces trois-là ont été soutenues par plusieurs personnes braillant un « vas-y, envoie ». Pohmelfs n'a pas été mergé, pour la simple raison que personne ne l'a demandé.

En dehors des correctifs sur les fichiers d'en-têtes et les 3 incorporations retardées, il n'y a que les correctifs habituels. Je serai plus strict en ce qui concerne les inclusions à partir de maintenant car il y a eu beaucoup de « bruit » et pas uniquement des corrections. J'en suis en partie responsable : une série de modifications d'Eric Paris visant à grandement améliorer l'usage de la pile dans le contexte SElinux.
La plupart des changements concernent quelques architectures (arm, tile, powerpc, x86) et les pilotes (particulièrement le réseau, mais aussi regulator, drm et mmc), ainsi que quelques mises à jour sur la gestion de l'énergie.

J'espère que la -rc3 aura un résumé carrément plus court.

RC-3

C'est le 15 avril que la version RC-3 a été annoncée par Linus :

Bon, ça fait donc huit jours depuis la -rc2, principalement parce que j'ai passé du temps à courir après deux bugs que je pouvais reproduire plutôt que de rendre cette version disponible hier. L'un était un oops dans la couche de gestion d'erreur scsi, et l'autre un plantage étrange sur x86-32. Bug introduit par mes soins. Oops.

Enfin bref, un jour de retard, mais nous sommes maintenant plus stables du fait de la correction de ces problèmes dans la -rc3. Les deux étaient suffisamment obscurs pour ne pas toucher grand monde, mais je déteste annoncer des versions candidates avec des problèmes que je peux reproduire personnellement.

Ceci dit, je ne pense pas qu'il y ait grand chose de bien excitant dedans. Il s'agit principalement de mises à jour de pilotes, avec une poignée de correctifs d'architecture et de réseau. Les statistiques de modifications sont assez barbantes, exception faite de la mise à jour du pilote mtip32xx et d'un changement trivial dans kyrofb (remplacement des unsigned long par u32, afin que ça fonctionne correctement en 64 bits) — cette RC se résume en gros par un bon nombre de simples remplacements.

Et des statistiques barbantes sont une bonne nouvelle. Cela signifie simplement « beaucoup de petits trucs ». Je l'admets, cela aurait été encore mieux si cela avait été « à peine quelques petits trucs », mais nous sommes raisonnablement tôt dans la séquence des versions candidates, je ne m'inquiète donc pas trop.

RC-4

La version RC-4 est disponible depuis le 21 avril :

Tout semblait calme depuis un moment, mais ça a changé hier. Je pense que soit les gens envoient leurs requêtes juste avant que je ne rende disponible les -rc, soit c'est un problème de gens qui travaillent de lundi à vendredi et qui finissent la semaine en m'envoyant leurs requêtes.
Peu importe le pourquoi, cela signifie que mon « oh, les choses se calment » de jeudi s'est transformé en « Uhhuh, en fait pas encore » le vendredi, quand plus de la moitié des modifications de cette -rc ont débarqué.

Ceci étant dit, même avec la pointe du vendredi, je pense que les choses ont tout de même été assez calmes. Nous avons eu quelques modifications annulées et un peu de nettoyage, mais la majorité sont des petits correctifs triviaux. Presque tous se situent dans les pilotes, avec quelques mises-à-jour du côté des systèmes de fichiers (la plupart étant des corrections de boutisme venant de Al) qui se sont glissées. Le traditionnel (sans renommage) fichier de différence est dominé par le déplacement du logo de démarrage m68k, mais nous utilisons tous les fichiers de différence de Git maintenant, n'est-ce pas ? Auquel cas, c'est 50% de pilotes (usb, mfd, xen, mmc, gpu, media…), 20% archi, 15% fs et une poignée de trucs ici et là.

Mais rien de tout cela n'a vraiment l'air effrayant. Il semble que la sortie de la 3.4 soit dans les clous, mais n'hésitez pas à brailler si vous repérez des régressions.

Je serai sans connexion pendant quelques jours (classe de plongée sous-marine, etc.), mais si le modèle « les gens m'envoient leurs trucs le vendredi » se vérifie, je parie que cela ne changera rien pour personne. D'autant que j'aurai mon portable et mon environnement de travail, donc si un truc surgit, tout se passera bien. Je ne suis simplement pas autant en ligne que d'habitude.

RC-5

Huit jours après la RC-4, Linus a annoncé sur la liste de diffusion la sortie de la version RC-5 :

À nouvelle semaine, nouvelle -rc. Techniquement ça fait 8 jours — j'ai retardé la sortie d'une journée dans l'attente de quelques tests.
Tout comme la -rc4, une bonne partie des modifications sont arrivées vendredi (et quelques autres hier). Et cela ne s'est pas calmé, au contraire. -rc5 a presque 50% de modifications en plus que n'en avait -rc4. Ce n'est pas bon.

Ceci étant dit, je ne pense pas qu'il y ait quoi que ce soit de très effrayant là-dedans. C'est ennuyeux, certes (je hais vraiment les vilains problèmes d'ABI d'autofs avec lesquels je me suis battu ces derniers jours, par exemple), et j'aurais préféré que les choses fussent plus calmes, mais la plupart des changements sont assez petits et triviaux. C'est réparti de manière assez équitable : 50% de pilotes, 20% d'architecture, 15% de systèmes de fichiers (principalement btrfs et nfs), 5% de réseau, ainsi que du bruit aléatoire.

RC-6

La grande nouvelle de la journée du 6 mai 2012 a bien évidemment été l'annonce de la version RC-6 par Linus :

Une nouvelle semaine, une nouvelle -rc — et je pense que nous sommes proches de la 3.4 finale. Merci donc de tester.

Il y a toujours plus de modifications que je ne le voudrais — et j'apprécierais que les choses se calment davantage encore, mais globalement les changements restent petits et simples.
Environ la moitié des modifications sont dans les pilotes (et la partie réseau représente presque la moitié de ça), le reste provenant principalement de arch (PowerPC et ARM), système de fichiers (Btrfs et NFS), ainsi que du réseau (hors pilotes).
Mais tous les changements semblent vraiment triviaux, donc, au final, je le sens plutôt bien.

En avant pour les tests.

RC-7

Enfin la dernière version candidate a été annoncé 12 mai 2012 :

C'est quasi certainement la dernière -rc de cette série : les choses se sont vraiment calmées, et j'ai même envisagé de rendre disponible le 3.4 en cette fin de semaine, pour finalement conclure qu'une semaine de plus ne pouvait pas faire de mal.

Le résumé des modifications donne une bonne vision d'ensemble : il s'agit principalement de petites corrections ici et là pour des petits problèmes très précis. La plus grosse modification (et celle qui touchera probablement le plus de gens) est le changement i2c de Nouveau — il s'agit de la suppression de la dernière modification. Les routines i2c spécifiques ayant leurs propres problèmes et les routines génériques i2c-algo-bit ayant été corrigées, Nouveau utilise maintenant les génériques.
Le reste est principalement constitué de petites modifications dans diverses zones : pilotes (réseau, DRM, SCSI, son et md), mises à jour d'archi (ARM, PowerPC et x86) et divers autres endroits : cœur du réseau, un correctif de compatibilité, des choses comme ça. Rien d'effrayant.

Alors lancez‐vous et testez. Et ne m'envoyez aucune demande d'inclusion à moins qu'elle ne contienne que des correctifs pour de très vilains bogues. Je ne veux plus de ces stupides correctifs pour supprimer des warnings du compilateur, etc.

En plus de cette annonce sur la LKML, Linus a décidé, comme il le fait régulièrement, de poster un petit texte sur son compte Google+, afin d’inciter les gens à tester cette dernière version candidate :

Dernière -rc avant la sortie de 3.4 ! Dépêchez-vous avant épuisement des stocks !
Du fait de l'édition limitée de 3.4-rc7, et si vous voulez que votre maman soit fière de vous demain, vous feriez bien de vous dépêcher. Et si vous êtes une maman, montrez à vos enfants que vous êtes exceptionnelle, car vos machines n'utilisent que le plus récent et le meilleur.
Parce que vous le valez bien.

Et si vous êtes un développeur, rendez-nous tous fiers en n'envoyant pas davantage de « correctifs des warnings du compilateur » ou autres modifications sans intérêt. Si vous m'envoyez une demande d'inclusion ou un patch destiné à la version finale de 3.4, il vaudrait mieux que cela concerne une regression majeure, un oops ou un correctif de sécurité.
Compris ?

Les nouveautés

Architecture x32

Aux côtés de ses cousines x86 et x86-64, la nouvelle architecture x32 fait son entrée dans le nouveau noyau Linux 3.4.

On sait que l’architecture x86-64 est une modernisation profonde de la vénérable architecture x86. Les registres généraux passent de 32 bits à 64 bits et leur nombre double (16 registres au lieu de 8). La mémoire virtuelle n’est plus limitée à 4 Gio, le bit NX est implémenté.  L’appel système SYSCALL64 est très rapide et les instructions vectorielles disponibles sont au moins au niveau du SSE2.
Toutes ces nouveautés, et le fait que sa prise en charge est désormais mature, font qu’il est de nos jours presque absurde d’utiliser une distribution en mode x86.

Néanmoins, certains développeurs sont d’avis que l’architecture x86 garde quelques avantages. Par exemple, le fait de se limiter à 32 bits signifie que les pointeurs mémoires sont plus petits et induisent donc moins de pression sur les mémoires caches du processeur. C’est un point important, notamment pour l’embarqué, car le bon fonctionnement du cache est absolument crucial pour les performances du processeur.
C’est quand même dommage de devoir choisir entre les indispensables 16 registres de x86-64 et l’empreinte mémoire réduite de x86. Serait‐il possible de créer une nouvelle variante qui ne retiendrait que les meilleurs aspects de ces deux architectures ?

C’est précisément le but qu’avait en tête H. Peter Anvin quand il a posté sur la LKML les patches proposant l’architecture x32.
Les programmes compilés avec l’ABI x32 tourneront donc en profitant à plein des 16 registres 64 bits (comme sous x86-64) mais leurs pointeurs mémoires seront limités à 32 bits (comme sous x86). Bien entendu, ces programmes seront limités à un espace d’adressage de 32 bits (4 Gio), mais cela ne constitue pas vraiment un obstacle pour la plupart d’entre eux, en particulier dans l’embarqué.

D’après les premiers tests, postés sur le site spécialement dédié à x32, les performances semblent encourageantes.
Le test 181.mcf du banc d’essais SPEC CPU2000 a été utilisé car il est extrêmement dépendant de la mémoire, et il profite à fond d’une réduction de la pression sur le cache. Selon ce test, effectué sur un processeur Core i7, on obtient un gain de vitesse d’environ 32 % par rapport au mode x86-64. Comme prévu les performances sont très proches de celles de x86 (moins d’1 % d’écart).
Le gain induit par les pointeurs mémoire 32 bits est donc bien visible.

Si l’on regarde le test 186.crafty, on devrait cette fois mettre en évidence le gain induit par l’utilisation des 16 registres 64 bits, puisque ce test est très dépendant du processeur. Là encore, la nouvelle architecture tient ses promesses, puisque l’architecture x32 n’est que 5 % plus lente que x86-64, mais qu’elle enregistre un gain de 29 % par rapport à x86.

Les patches de H. Peter Anvin ont été assez bien accueillis sur la liste de diffusion du noyau, mais Linus a quand même grogné sur un point précis. À l’origine, les valeurs relatives à la gestion du temps (time_t, off_t ou timeval) devaient être en 32 bits, ce qui impliquait que l’architecture x32 serait soumise au bogue de l’an 2038 (débordement du nombre de secondes entre 1970, l’origine du temps UNIX, et l’année 2038).
Linus a été prompt à envoyer un Scud en soulignant que ce point était inacceptable :

J’ai eu des journalistes qui m’ont posé la question et j’ai toujours répondu qu’en 2038 nous utiliserions tous des processeurs 64 bits. Je pense que c’est une réponse tout à fait raisonnable.
Mais si ces processeurs 64 bits font en fait tourner un mode « rapide » 32 bits, alors cette réponse perd toute sa pertinence. À notre époque, c’est une erreur fondamentale que d’avoir off_t et time_t en 32 bits. Je détesterais d’avoir à introduire ça dans le noyau, ça me ferait gerber.

Ce point a été rapidement corrigé en introduisant une gestion du temps spécifique sur 64 bits pour l’architecture x32 (c’est la fonction COMPAT_USE_64BIT_TIME). D’autres objections ont été soulevées, mais les révisions successives des patches ont finalement convaincu Linus d’intégrer cette ABI x32 dans la branche principale du noyau.

Bien entendu, un tel changement mixant les caractéristiques de plusieurs architectures a des impacts bien au-delà du noyau Linux. La gestion de la nouvelle architecture x32 doit être ajoutée dans GNU binutils, dans la Glibc et dans le compilateur GCC. Les distributions binaires doivent décider d'utiliser ce mode et proposer des exécutables x32 dans leur dépôts.
C'est donc un travail de longue haleine qui commence et nous verrons dans les prochaines années si l'architecture x32 arrive à convaincre dans le monde de l'embarqué.

dm-verity

La couche du device‐mapper présente dans le noyau est une interface virtuelle servant à faire communiquer entre eux des périphériques blocs. Cette gestion des volumes logiques permet, par exemple, de faire du RAID logiciel ou du chiffrement de disques entre divers périphériques en mode bloc.
La couche device-mapper du noyau 3.4 accueille un nouveau module nommée dm‐verity, qui fera sans doute quelque peu polémique auprès des libristes les plus vigilants.

Le but de dm-verity est de vérifier l’intégrité des blocs de données d’un périphérique. Pour cela une empreinte est prise pour chaque bloc et chacune d’entre elles est mise en correspondance sur son bloc respectif via dm-verity. Comme le périphérique virtuel est monté en mode lecture seule, il n’est pas possible de changer l’empreinte, ce qui assure l’intégrité des données contre toute tentative de modification frauduleuse.
Bien entendu, pour que la chaîne de confiance soit absolue, il faut que la machine puisse avoir une phase d’amorçage protégée. Cela se fait en utilisant tboot ou TrustedGRUB, ou encore en démarrant à partir d’une clé USB ou d’un CD considérés comme sûrs. L’utilisateur de dm-verity va alors fournir au système l’empreinte de la racine, et cette information est la clé qui permettra de vérifier, de proche en proche, que les blocs du périphérique (et donc les exécutables) n’ont pas été modifiés. C’est la technique classique de l’arbre de hachage qui est ici utilisée (Merkle tree).
La documentation indique que la vérification se fait via l’outil veritysetup avec la syntaxe suivante :

veritysetup -a vroot /dev/sda1 /dev/sda2 hash_de_la_racine

Théoriquement à ce stade le lecteur attentif des dépêches noyau LinuxFr devrait se demander « Mais en quoi est‐ce différent du sous‐système EVM qui avait été décrit dans la dépêche Linux 3.2 ? ».
Excellente question cher lecteur attentif ! Eh bien, tout d’abord, EVM fonctionne obligatoirement avec une puce TPM (Trusted Platform Module), alors que dm-verity n’a pas cette dépendance. Il peut utiliser une puce TPM (via TrustedGRUB notamment), mais, comme nous l’avons vu plus haut, il peut aussi se contenter d’un amorçage à partir un périphérique externe qui aura été gardé en lieu sûr (clé USB ou CD).
Ensuite, la vérification des empreintes se fait seulement à la demande, quand le noyau à besoin de réellement accéder aux blocs sous‐jacents (lors d’un accès disque). Cela évite une coûteuse phase de vérification de toutes les empreintes lors du démarrage, ce qui améliore donc les performances.

Le développeur Mandeep Singh Baines a indiqué que dm-verity était déjà utilisé par Google dans son projet Chrome OS :

dm-verity fait partie de l'infrastructure de boot sécurisée de Chrome OS. Le module est utilisé pour vérifier l'intégrité du système de fichiers root lors du démarrage. Cette partition root est montée via un mapping dm-verity afin de vérifier, de façon complètement transparente, que chaque bloc correspond au hash qui a été passé lors du boot.

Une présentation de dm-verity a été effectuée lors du sommet Plumber 2011 qui s’est déroulé à San Diego en août dernier. Dans le fichier PDF de présentation, on apprend que la vitesse de vérification a été un facteur crucial lors du choix d’architecture de dm-verity. Certes, EVM est une solution plus complète, mais la nécessité de ne pas ralentir le démarrage d’une machine Chrome OS a conduit au développement de cette alternative. Avec dm-verity, il est ainsi possible d’amorcer en 1,2 seconde une partition root de 891 Mio.

Bien entendu, cette technique de vérification d’intégrité peut aussi être utilisée par des constructeurs peu scrupuleux qui voudraient bloquer l’accès des utilisateurs à leur machine. Il est particulièrement inquiétant de lire le courriel envoyé sur la LKML par Wesley Miaw qui travaille pour Netflix. Cette société américaine propose un service payant de diffusion vidéo. On comprend facilement qu’elle puisse chercher à bloquer l’enregistrement de ce flux vidéo sur les smartphones et tous les autres périphériques basés sur Linux :

Netflix voudrait que dm-verity soit incorporé dans le noyau Linux. Au cours de l'année écoulée, nous avons travaillé avec Google afin de porter dm-verity sur un certain nombre de périphériques électroniques grand public tournant sous une version embarquée de Linux.
La demande pour cette fonction a été importante et nous voyons pas mal de bénéfices à ce que dm-vérity fasse partie du noyau officiel.

Netflix a une politique de certification officielle des plates‐formes avant que l’utilisateur ne puisse accéder au flux vidéo (voir cet exemple avec les smartphones OMAP 4). On peut craindre que dm-verity ne soit utilisé pour bloquer toute tentative de changement des binaires, et que l’empreinte racine ne reste entre les mains du constructeur. Ce ne serait pas la première fois qu’une technologie potentiellement utile serait ainsi détournée pour asservir les utilisateurs.
Comme le résume Jonathan Corbet sur l’article de LWN dédié à ce sujet :

Certains vendeurs vont, sans aucun doute, choisir d'inclure des outils comme dm-verity sans donner aux utilisateurs la possibilité de le désactiver. Ce n'est pas une bonne chose, mais ce n'est pas non plus quelque chose de nouveau.

Nouveautés pour l'architecture ARM

L'architecture ARM a le vent en poupe en ce moment et le noyau Linux 3.4 accueille de nombreuses nouveautés qui améliorent sa prise en charge et ajoutent des fonctionnalités.

La première de ces nouveautés est l'unification de la gestion des horloges dans un nouveau sous-système dédié nommé « Common CLK ».
C'est un travail de longue haleine qui a été entrepris par Mike Turquette, Jeremy Kerr et Ben Herrenschmidt puisque la première version a été proposée sur la LKML il y a plus d'un an.
Auparavant le noyau Linux gérait de façon complètement séparée ce code de gestion des horloges matérielles. Chaque implémentation vivait dans des répertoires dédiés aux diverses architectures. Plutôt que cette solution inefficace d'un code spécifique pour chaque plateforme, le nouveau sous-système propose une gestion matérielle unifiée :

The common clk framework is an interface to control the clock nodes available on various devices today. This may come in the form of clock gating, rate adjustment, muxing or other operations. The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.

La documentation indique que l'option de configuration COMMON_CLK doit être choisie lors de la compilation et que l'interface est divisée en deux parties bien distinctes. La première s'appuie sur le code commun (un struct clk unique ainsi qu'une API unifiée dans include/linux/clk.h) tandis que la seconde regroupe les callbacks spécifiques qui s'enregistrent avec clk_ops.
Maintenant que ce sous-système commun unifié est disponible on va sans doute assister à la conversion progressive des pilotes dans les prochaines versions du noyau.

Ce travail n'est pas vraiment spécifique à l'architecture ARM mais, étant donné la diversité qui existe sur cette architecture, c'est pour elle que ses effets bénéfiques vont se faire sentir avec le plus de force. Alors qu'avant il était impossible de compiler une image noyau identique pour deux plateformes ARM ayant des struct clk différentes, il devient maintenant envisageable, à moyen terme, d'avoir une image multi-plateforme unique pour ARM. Moins de duplication de code et, comme l'écrit Mike Turquette, le but est bien d'avoir « The One Image to Rule Them All » !

Outre cette infrastucture « Common CLK » le noyau 3.4 accueille également les patchs de DMA-mapping qui ont été écrits par Marek Szyprowski. Le DMA (Direct Memory Access) c'est la possibilité d'envoyer les données d'un périphérique directement dans la mémoire RAM, sans intervention du processeur. Bien entendu, cette technique doit tenir compte des particularités de l'architecture matérielle sous-jacente et une API unifiée est disponible dans le noyau Linux.
Le problème, c'est que les développeurs ARM n'utilisaient pas vraiment ce code commun et qu'une certaine « balkanisation » était observée dans l'arbre des sources. Marek a mis fin à cette anarchie et ses patchs simplifient la gestion des particularités de l'architecture ARM.

Encore une nouveauté ARM intégrée dans ce noyau 3.4, la fonction « jump label » est maintenant utilisable pour les machines ARM et Thumb-2.
Comme indiqué dans la dépêche du noyau 2.6.37 cette fonction « jump label » (d'ailleurs renommée depuis en « static keys ») permet de réduire drastiquement le coût des points de traçage, mais elle nécessite d'écrire un code assembleur adapté à chaque architecture. C'est Vincent Rabin qui s'est chargé de ce travail pour ARM et cette fonction est utilisable avec l'option de configuration HAVE_ARCH_JUMP_LABEL.

Le JIT (compilateur à la volée) qui permet d'accélérer le traitement des paquets réseau du filtre Berkeley Packet Filter, est maintenant disponible sur architecture ARM.
Cette fonction est utilisable via l'option HAVE_BPF_JIT et elle s'active avec un petit echo 1 > /proc/sys/net/core/bpf_jit_enable.

Enfin, du côté de la prise en charge du matériel, le développeur Peter De Schrijver a écrit un patch ajoutant la gestion de la plateforme Tegra3 avec son « processeur compagnon ». On voit ainsi que NVidia, société pour laquelle travaille Peter, souhaite améliorer la prise en charge native de ses SoCs dans la branche principale.
Le noyau 3.4 apporte également la prise en charge de la plateforme Exynos5 de Samsung. C'est le tout premier System on Chip à utiliser le nouveau coeur Cortex-A15.

YAMA

Après plus d'un an et demi d'hésitations et de débats, le module de sécurité YAMA a finalement été intégré dans le noyau Linux 3.4.
Cet ajout est une bonne occasion pour évoquer les controverses qui persistent entre les développeurs au sujet de la sécurité de Linux. Il a toujours été difficile de trouver un équilibre entre la sécurité à tout prix, au détriment même de la propreté du code et de sa maintenabilité, ou bien une approche plus pragmatique et mesurée.

Tout commence le 16 juin 2010 avec un mail de Kees Cook sur la liste de diffusion du noyau. Kees, qui était alors responsable sécurité chez Canonical, soutient que l'appel système ptrace est potentiellement dangereux et il propose un patch pour bloquer cette faille.
La commande ptrace est souvent utilisée pour les phases de déboguage car elle permet à un processus d'éditer l'espace mémoire d'un autre processus. D'après Kees Cook, un attaquant peut exploiter cette capacité afin d'élargir la surface d'attaque d'une compromission initiale :

Une faiblesse particulièrement troublante de l'interface des processus sous Linux est qu'un simple utilisateur peut examiner le statut et la mémoire de chacun de ses processus.
Par exemple, si une application (par exemple Pidgin) est compromise, alors il est possible pour un attaquant de s'attacher à un autre processus (par exemple Firefox, une session SSH, un agent GPG, etc.) afin d'extraire des informations sensibles additionnelles et continuer son attaque.

Le patch de Kees est simple puisqu'il se contente d'ajouter un sysctl (une interface de paramétrage) contrôlant le comportement de ptrace. Ce nouveau paramètre, nommé ptrace_scope, peut prendre les valeurs « 0 » ou « 1 ». Par défaut, c'est « 0 » qui est utilisé (mode « classic ») et cela signifie que le comportement de ptrace ne change pas par rapport à la situation actuelle. En revanche, quand ptrace_scope est à « 1 » (mode « restricted »), alors un processus ne peut lancer ptrace que sur ses processus fils et toute tentative d'examiner la mémoire des autres processus échouera.

On notera que le travail de Kees Cook s'inspire largement d'une fonction qui existe déjà dans Grsecurity. L'option CONFIG_GRKERNSEC_HARDEN_PTRACE interdit en effet de lancer ptrace sur des processus arbitraires et limite le choix aux processus fils.

Les réactions sur la LKML n'ont pas été d'un enthousiasme délirant et Alan Cox a été prompt à manifester son opposition au patch de Kees :

Les autres distributions font ça de façon rationnelle en utilisant des choses comme SELinux. Cela permet de décrire les relations de façon complète et on contrôle tous les chemins d'accès, pas seulement ptrace, pouvant être utilisés par un attaquant.
Même si tu t'en tapes d'utiliser les mêmes fonctions de sécurité que le reste du monde, de toute façon ton patch, et les autres trucs que tu as postés, tout ça doit aller dans un module de sécurité à part.
Donc NAK. Si tu veux réutiliser des morceaux de grsecurity alors, s'il te plaît, écris un module noyau grsecurity qui se basera sur les hooks qui existent. Arrête de pourrir le cœur du code. C'est aussi simple que ça. L'infrastructure existe alors utilise-là.

James Morris, le responsable de SELinux, a même souligné que son module de sécurité avait déjà un booléen, nommé allow_ptrace, et permettant de contrôler le comportement de ptrace. Pourquoi alors réinventer la roue ?
Le problème c'est que tout le monde ne veut pas utiliser SELinux. Les réfractaires sont nombreux et ils sont d'avis que SELinux est trop compliqué à utiliser. Même un hacker aussi réputé que Ted Ts'o avoue être découragé :

Il y a un bon nombre de gens qui n'utiliseront jamais SELinux. Tous les deux ou trois ans, je jette un nouveau coup d'œil sur SELinux, ma tête explose devant la complexité (non nécessaire ÀMHA) et je prends une nouvelle fois le large.

La situation paraît donc complètement bloquée entre les zélotes d'un module SELinux ultra-puissant mais complexe et les partisans d'une solution plus simple, même si elle est moins complète.
La solution régulièrement évoquée pour faire face à ce problème est « l'empilage des modules de sécurité » (LSM stacking). Avec cette solution, il devient possible d'avoir un « gros » module qui couvre le cas général (comme SELinux) et un ou plusieurs autres modules qui ne s'occupent que de fonctions bien précises sur lesquelles l'utilisateur veut avoir le contrôle.
Actuellement, le code LSM du noyau ne permet le chargement que d'un seul module de sécurité, à l'exclusion de tous les autres. Avec le LSM stacking cette limitation disparaîtrait et le noyau Linux offrirait plus de souplesse à ses utilisateurs.

En attendant que les développeurs se mettent d'accord sur une solution technique propre pour implémenter cet empilage des modules, Kees Cook a donc réécrit son patch afin d'isoler le code à l'intérieur d'un nouveau module de sécurité nommé YAMA.
En plus de la restriction d'utilisation de ptrace, on trouve dans le module des protections supplémentaires sur l'utilisation des liens symboliques (symlink) et des liens matériels (hardlink).

L'intégration du module YAMA a été proposée sur le LKML le 21 juin 2010… mais, dès le 2 août, Kees a posté un message indiquant qu'il était obligé de retirer le module puisque Christoph Hellwig avait posé un veto empêchant l'inclusion dans le noyau.
Les objections de Christoph se concentrent sur le fait que YAMA n'est pas un module de sécurité cohérent et qu'il n'est qu'une collection hétéroclite de divers patchs visant à bloquer des failles potentielles.

À ce stade de la situation on ne peut que comprendre la frustration de Kees :

Je commence à être fatigué de devoir porter mes patchs d'un côté ou de l'autre entre les sous-systèmes ou les modules de sécurité. Vous m'avez demandé de tout mettre dans un module et maitenant vous me dites que je ne devrais pas faire ça.
La situation est très simple. Soit vous me laissez mettre tout ça dans un module pour que les gens puisse choisir de l'activer. Soit vous m'aidez à améliorer les patchs, afin qu'ils intégrent directement les sous-systèmes.
Comme la seconde solution a été refusée à plusieurs reprises, il m'a été suggéré d'opter pour la première, ce que j'ai fait. L'option de tout abandonner n'est pas envisageable.

La flame war discussion a donc été relancée et certains développeurs ont tenté d’expliquer à Kees ce qu’ils reprochaient à ses patchs :

Tu n'évoques pas la solution que t'a suggérée Al : Il faut avant tout réfléchir au problème de façon approfondie au lieu de balancer des patchs qui ne s'occupent que d'un seul cas de figure.
Ici on ne bloque qu'un seul type spécifique d'attaque sans créer un modèle conceptuel de la menace. C'est la grande distinction entre SELinux, Tomoyo, Smack et puis tes patchs à toi. Ces modules de sécurité forment un modèle de ce qui est important à protéger et de comment le protéger. Ils ne se contentent pas d'appliquer des règles arbitraires pour empêcher certaines attaques.
Les gens s'inquiètent parce que ton module pourrait grossir en accumulant des tonnes de règles spécifiques qui créeraient une sécurité apparente sans vraiment procurer une sécurité réelle.

Kees Cook a tenté de faire valoir son point de vue et a souligné la situation impossible dans laquelle il se trouvait confiné :

Vous pouvez voir, comme moi, que la situation est un catch 22. « Nous n’avons pas besoin de la fonction d’empilage parce qu’il n’y a rien à empiler » et « nous n’avons pas besoin d’un micro‐module parce qu’il est impossible d’empiler les modules. »

Le blocage étant total, il a été décidé d’attendre la prochaine conférence sur la sécurité du noyau, afin que la situation se décante et que les protagonistes puissent se parler directement. C’est donc en septembre 2011 que James Morris et les autres développeurs responsables de la sécurité se sont retrouvés. Dans le programme, on peut voir que Kees Cook animait une discussion portant le titre suivant: « LSM Architecture: modularity, stacking ».
Le compte‐rendu que Paul Moore a fait du Linux Security Summit 2011 indique que le sommet a bien joué son rôle et que l’avis des développeurs a changé au sujet du l’empilement et de la concurrence entre les modules. Cette évolution s’est matérialisée en mars 2012 quand James Morris a officiellement accepté d’intégrer le module de sécurité YAMA dans sa branche destinée au noyau Linux 3.4. Le fait que ce code soit déjà en cours d’utilisation dans divers projets n’est sans doute pas étranger à cette inclusion :

Le principal ajout est le nouveau module de sécurité YAMA, écrit par Kees Cook, et qui a été discuté l'année dernière au sommet sur la sécurité. Son but est de rassembler divers mécanismes de sécurité DAC en un seul endroit. Cela marque également un changement de politique en ce qui concerne les modules LSM qui étaient auparavant tous des mécanismes complets de contrôle d'accès.
Chromium OS utilise YAMA et je crois qu'il y a des plans pour Ubuntu.

Kees a précisé qu'en fait Ubuntu utilisait déjà YAMA depuis octobre 2011 et il a également fourni un lien vers l'inclusion de YAMA dans Chromium OS.
Selon la documentation présente dans les sources du noyau, on voit que seule la restriction de ptrace a été implémentée pour l"instant dans YAMA (just ptrace restrictions for now). Il est fort probable que les autres restrictions, celles qui concernent symlink et hardlink, intégreront plus tard le module.

Un choix est donc désormais offert entre l'implémentation (souvent difficile) d'une politique de sécurité complète ou bien l'activation d'un module visant à regrouper divers patchs de renforcement de la sécurité.
Nous verrons dans les prochains noyaux si la solution idéale que constituerait le « stacking LSM » parviendra à s'imposer.

En bref

Maturation de btrfs

Les distributions de Novell (SuSE Linux Enterprise) et d'Oracle (Unbreakable Enterprise Kernel) veulent absolument se différencier par rapport à Red Hat. C'est pour ça qu'elles ont choisi de supporter officiellement (1 - 2) le système de fichiers btrfs, même si il est encore considéré officiellement comme « experimental » dans la branche principale du noyau.
Leurs patchs de fiabilisation arrivent maintenant dans le noyau 3.4 afin que tous les utilisateurs puissent en profiter.
On trouve donc un gros patch de Jeff Mahoney, employé par SuSE, qui améliore la gestion des erreurs. Auparavant, c'était un simple et rustique appel à la macro BUG_ON qui était souvent utilisé (on enregistre l'erreur et on arrête le système). Maintenant la plupart des erreurs bénéficient d'un traitement spécifique et le crash du noyau est évité. Comme le résume Chris Mason :

Nous avons mergé les patchs de gestion d'erreurs venant de SuSE. Ils sont déjà incorporés dans le noyau SLES et ils apportent à Btrfs la possibilité d'interrompre les transactions et de passer en mode lecture seule en cas d'erreur.

Le message de Chris récapitule les autres nouveautés concernant btrfs pour cette version du noyau. On peut voir notamment qu'un gros travail de performances a été effectué sur la gestion des métadonnées, sur la coopération avec le cache de page de Linux ou encore sur la réduction de l'empreinte CPU (voir par exemple les patchs de Josef Bacik).
En ce qui concerne les métadonnées du système de fichiers il est possible d'utiliser des blocs plus grands que 4 Ko. La limite est maintenant portée à 64 Ko et les tests montrent que l'optimum du gain de performances est atteint avec une taille de bloc égale à 32 Ko. Cette fonction s'active lors de la création du système de fichiers avec mkfs.btrfs -l 32K.

Tout ce travail d'optimisation des performances porte ses fruits si on compare les graphes postés par Chris Mason entre les versions 3.3 et 3.4 du noyau.

Simplifications dans ext4

En ce qui concerne le système de fichiers ext4, il n'y a pas de changements révolutionnaires, mais on trouve néanmoins plusieurs patchs de nettoyage intéressants.
Ted Ts'o, qui peste depuis plusieurs mois devant le nombre d'options présentes dans ext4, a procédé à diverses simplifications du code. Par exemple, l'option de montage journal=update, qui a été introduite il y a dix ans pour faciliter les migrations depuis ext3, a été retirée du noyau 3.4. C'est la même chose pour l'option resize permettant de changer la taille lors du mount. Après tout, on utilise resize2fs alors pourquoi avoir cette option redondante ?
Un autre patch utilise une table pour stocker les options de mount, ce qui, là encore, simplifie le code puisqu'on peut supprimer une centaine de lignes.
Ted a également proposé de retirer les options bsddf et minixdf qui conduisent l'outil df à se comporter comme sous BSD ou MINIX… mais les cris d'orfraie sur la LKML l'ont finalement dissuadé.
Pas découragé pour autant, il a fait remarquer qu'ext4 était le seul système de fichiers à proposer une option permettant l'activation ou la désactivation des attributs étendus lors du mount (options noacl et nouser_xattr). C'est fort peu utile, mais avant de supprimer ce code, il faut tout de même alerter la communauté. Son patch se contente donc pour l'instant de marquer ces options comme obsolètes (deprecated) et elles seront probablement retirées dès le prochain noyau.

fadump pour PowerPC

Dans cette version du noyau, l’architecture PowerPC a gagné un mécanisme de capture des données (dump) lors d’un éventuel crash de la machine. Ce nouveau système repose sur une coopération avec le micro‐logiciel, le firmware, ce qui explique son nom de fadump (firmware assisted dump).

Lors du démarrage initial, le noyau se sert du firmware Power pour sélectionner des régions de la mémoire et les réserver au stockage des données pour analyse post-mortem. Au moment du crash, c’est le firmware qui prend la main et qui sauve les données (ainsi que les registres système et les entrées dans la table des pages).
Après ces opérations, l’administrateur peut redémarrer normalement. Le noyau va noter qu’il y a eu un crash (puisqu’une entrée dump-kernel aura été créée) et il va soigneusement éviter de toucher les zones mémoire réservées. Un programme en espace utilisateur pourra ensuite être utilisé pour lire /proc/vmcore et récupérer ces données pour analyse ultérieure. Ensuite, il ne faudra pas oublier de faire un petit echo 1 > /sys/kernel/fadump_release_mem pour libérer la mémoire qui avait été réservée au stockage des données du crash.

La documentation de fadump écrite par Mahesh Salgaonkar explique les deux avantages de cette procédure par rapport aux classiques kexec et kdump. Tout d’abord, le système est réinitialisé proprement avec une version fraîche du noyau, et ensuite, aussitôt que la copie du dump est effectuée, la mémoire peut être réutilisée. Pas besoin d’un nouveau redémarrage.
Pour profiter des avantages de fadump, il vous faudra un noyau compilé avec l’option de configuration CONFIG_FA_DUMP.

UFS dans le noyau

Le titre de ce paragraphe peut prêter à confusion, puisqu’il ne s’agit pas du système de fichiers bien connu Unix File System, mais bien de la norme Universal Flash Storage.
C’est l’organisation de standardisation JEDEC qui s’est chargée de créer cette nouvelle norme destinée au stockage sur mémoire Flash dans les appareils mobiles (smartphones, tablettes ou encore appareils photo). De nombreuses sociétés de l’embarqué (Nokia, Sony Ericsson, Texas Instruments, STMicroelectronics, Samsung, etc.) ont travaillé à l’élaboration de la norme, afin qu’elle offre une plus grande vitesse et une moindre consommation que le standard actuel des cartes SD. L’architecture de communication utilisée est similaire à SCSI afin de profiter de la gestion des commandes multiples et d’offrir un modèle de programmation bien connu.

Les patchs de Santosh Yaraganavi ajoutent au noyau le pilote UFS pour le host controller. Selon la documentation, un peu de travail reste à faire en ce qui concerne la gestion de la consommation, mais on peut noter que les systèmes basés sur Linux sont les premiers à offrir la gestion de la norme Universal Flash Storage.

Camellia et CRC32

L’optimisation des algorithmes de chiffrement va peut‐être devenir un paragraphe récurrent des dépêches noyau. En effet, après les patches évoqués dans les dépêches du 3.2 et du 3.3, le développeur finlandais Jussi Kivilinna a frappé de nouveau.

Cette fois, c’est l’algorithme Camellia qui est concerné. Rappelons qu’il s’agit de l’algorithme de chiffrement symétrique 128 bits arrivé en tête lors du concours NESSIE de l’Union européenne.
Comme pour ses patches précédents Jussi a écrit une implémentation en assembleur optimisé pour l’architecture x86_64 (camellia-x86_64-asm_64.S). Le gain en performances est tout à fait notable par rapport au code C générique du noyau puisque, sur un processeur Core 2 T8100, on relève un écart s’échelonnant de 10 % à plus de 70 % (en mode ECB).

Jussi Kivilinna n’est pas le seul à traquer la performance, et le noyau Linux 3.4 incorpore également les patches CRC32 de Bob Pearson. Le contrôle de redondance cyclique (CRC pour Cyclic Redundancy Check) est utilisé partout afin de détecter les erreurs de transmission, et il est important que le code soit optimisé soigneusement.
Bob a modifié le fonctionnement de la routine lib/crc32.c afin de remplacer la boucle principale et la boucle rem_le par des compteurs à incrémenter. Selon les tests, on peut espérer un gain supérieur à 6 % sur architecture x86.
Comme le code semble dégrader les performances des PowerPC, il a été entouré de ifdef CONFIG_X86, afin de ne pas pénaliser les autres architectures.

Discard pour « thin provisioning »

Depuis le noyau 3.2, la couche device mapper permet de faire de l’allocation fine et dynamique (thin provisioning). Dans le cadre d’un SAN, plutôt que d’allouer vraiment tous les blocs à un client, on va les allouer à la volée pour économiser de l’espace. Chacun des clients aura un volume virtuel à sa disposition, mais ce volume n’occupera que l’espace réellement consommé.

Cette cible DM de « thin provisioning » est maintenant capable de gérer la fameuse fonction discard. Cette commande est très importante pour les disques de stockage de type SSD (à base de mémoire Flash), car elle permet au système d’exploitation d’indiquer au disque quels sont les blocs de données qui peuvent être effacés. Dans le cas du thin provisioning, un appel à discard provoquera la suppression des correspondances (mappings) et, si les blocs ne sont plus partagés, l’ordre de suppression sera envoyé au périphérique sous‐jacent.

Cette utilisation plus efficace du périphérique de stockage n’est pas la seule nouveauté intégrée dans la fonction de thin provisioning du noyau 3.4. On trouve également la possibilité d’utiliser des images en lecture seule comme origine. La lecture des blocs s’effectue sur cette image, tandis que les écritures se font sur un autre périphérique.
C’est très utile dans le cas des environnements virtualisés, puisque l’hôte peut ainsi accueillir les systèmes invités sur un volume géré par thin provisioning, tout en ayant l’image de base stockée sur un autre périphérique partagé entre les machines virtuelles.

IRQ domains

Une IRQ c’est une demande d’interruption (Interrupt Request) envoyée au processeur pour lui signaler que le matériel a besoin qu’une action urgente soit effectuée (entrée‐sortie, avancement d’une horloge, défaut matériel, etc.).
Linux se doit de gérer parfaitement les machines qui ont plusieurs contrôleurs d’interruptions et, pour atteindre ce but, un nouveau sous‐système nommé IRQ domains fait son entrée dans le noyau 3.4.

Auparavant c’étaient les fonctions irq_alloc_desc et irq_free_desc qui étaient utilisées afin d’éviter les collisions dans les assignations des numéros des interruptions.
Ce mécanisme ayant été jugé perfectible (pas de possibilité de faire du reverse mapping), un nouveau système propre et générique a été développé. Il s’inspire du code PowerPC et s’active avec l’option de configuration IRQ_DOMAIN.
Comme l’explique la documentation, ce mécanisme générique permet maintenant au noyau Linux de gérer proprement la correspondance entre les IRQ des divers contrôleurs (hwirq) et l’espace global des interruptions.

Pilote virtio-scsi

Virtio est une interface virtuelle qui permet au noyau de gérer efficacement les entrées‐sorties pour les systèmes virtualisés. C’est le pilote virtio-blk qui s’occupe des périphériques en mode bloc, mais, à partir de ce noyau 3.4, une alternative devient disponible. Elle prend la forme du pilote virtio-scsi écrit par Paolo Bonzini, un développeur Red Hat.

Ce pilote virtio-scsi propose le multiplexage (plusieurs unités de stockage logiques sur un seul port PCI), mais son auteur le définit surtout comme plus extensible que virtio-blk. Avec ce dernier, il est nécessaire de définir la liste des fonctionnalités du périphérique, et chaque ajout implique une mise à jour de cette spécification, de l’hôte QEMU, ainsi que des pilotes des systèmes invités.
Avec virtio-scsi, l’hôte fournit juste une couche de transport SCSI, et les ajouts de fonctionnalités se feront plus facilement (Paolo cite les fonctions discard, extended copy, ainsi que write same).
Les développeurs Linux n’aiment pas vraiment introduire du code qui fait doublon dans le noyau, et Paolo a dû batailler ferme pour convaincre James Bottomley de l’utilité de son pilote aux côtés de virtio-blk.
Pour profiter de ce pilote alternatif sur vos systèmes, il vous faudra un noyau compilé avec l’option SCSI_VIRTIO. Ce code est encore considéré comme expérimental pour le moment.

Du côté de -staging

Pas mal de mouvements dans cette branche -staging dédiée au code pas encore assez mature pour rejoindre la branche principale.
Par exemple, les mécanismes « zcache » et « zram », qui s’occupent de compresser les pages mémoire, bénéficient d’un nouvel allocateur mémoire. Auparavant, c’était l’allocateur xvmalloc qui était utilisé, mais un remplaçant plus efficace a été développé par Nitin Gupta. Ce nouvel allocateur se nomme zsmalloc et il est conçu tout spécialement pour stocker des pages RAM compressées et réduire la fragmentation.
Par ailleurs, le mécanisme de compression zcache utilise maintenant le sous‐système CRYPTO du noyau pour son algorithme de compression. Avant, c’était un code ad hoc qui était employé mais les développeurs Linux ont fermement indiqué qu’il fallait réutiliser le mécanisme standard. On peut choisir son algorithme au démarrage avec une syntaxe du type zcache=lzo ou zcache=deflate.
Greg Kroah-‐artman ayant indiqué qu’il n’accepterait plus aucun ajout de fonction, on peut penser que ces patches seront les derniers avant la sortie de -staging pour zcache et zram.

Toujours dans -staging les patchs écrits par Arve Hjønnevåg ajoutent la prise en charge des alarmes Android dans le noyau. Encore un petit pas vers la gestion intégrale d'Android dans la branche principale.

Le sous-système « RAMster », après un petit imbroglio initial, a également été intégré dans -staging (1 - 2). L’idée derrière RAMster est très intéressante, puisqu’il s’agit de permettre aux machines au sein d’une grappe de serveurs (cluster) de créer une sorte de réserve commune de mémoire vive. Ainsi, quand une machine est un peu juste en RAM et sur le point de devoir faire appel à la partition d’échange (le swap), elle va pouvoir envoyer ses données dans la RAM de sa collègue.
Le mécanisme est toutefois complexe (voir la documentation) et il faudra attendre sa stabilisation avant de le voir intégrer la branche principale.

Enfin, petit évènement, le dernier morceau du pilote de virtualisation Hyper-V écrit par Microsoft quitte enfin la branche -staging. Vous pouvez maintenant « profiter » de ce pilote en passant les options de configuration HYPERV et HYPERV_STORAGE lors la compilation.
C’est la fin d’une saga débutée en juillet 2009, et qui, du fait des atermoiements et des problèmes de qualité du code, n’aura pas redoré le blason de la firme de Redmond.

Pilote graphique Nouveau

Pour faire une habile transition avec la brève précédente consacrée à -staging, notons le patch de Ben Skeggs, qui transfère le pilote Nouveau de -staging vers drivers/gpu/drm. Jusqu’à présent, les développeurs considéraient que Nouveau était encore susceptible de changer son interface binaire et donc devait rester dans l’antichambre du noyau. Le passage en version 1.0 marque un engagement de stabilité et autorise maintenant une sortie de -staging.
Comme l’écrit Ben :

Il n’y a pas vraiment de raison de rester dans cette branche, de toute façon nous devons maintenir l’ABI pour éviter d’énerver les gens.

Ben a également ajouté le code permettant de faire fonctionner la toute récente carte de type Kepler (GeForce GTX 680). Attention toutefois, puisqu’il ne s’agit pas, pour l’instant, d’exploiter la puissance de cette carte, le patch n’ajoute que la gestion des modes d’affichage (mode setting), ce qui permet d’éviter d’avoir à se rabattre sur VESA.

Les autres pilotes graphiques

Le pilote DRM dédié au système mono‐puce (SoC) Samsung Exynos gagne une prise en charge de la norme HDMI 1.4 et un pilote virtuel permettant la gestion des écrans sans fil.

Côté AMD, on voit arriver la prise en charge des cartes Southern Islands (Radeon HD 7700, 7800 et 7900), ainsi que des processeurs Fusion de type Trinity. Les cartes Northern Islands reçoivent des patches écrits par Jérome Glisse et permettant la prise en charge du pavage (tiling) 2D.
Pour avoir une idée de la complexité du travail des développeurs de pilotes GPU, vous pouvez d’ailleurs aller lire cette publication de Jérome, dans laquelle il raconte la difficile traque d’un bogue affectant la sortie VGA des puces Llano.

Du côté d’Intel, le pilote i915 active enfin par défaut le mode d’économie d’énergie RC6 sur les puces Sandy Bridge. On trouve également la possibilité d’entrelacer les flux HDMI et SDVO en sortie, ainsi qu’une amélioration des performances d’environ 10 % grâce aux patches PGTT (Per-process Graphics Translation Table) et Swizzling.

HSI

Le noyau 3.4 accueille les patches de Carlos Chinea, qui travaille pour Nokia. Ils permettent la gestion du sous‐système HSI (High Speed Synchronous Serial Interface).
Il s’agit d’un bus série utilisé dans les téléphones mobiles et destiné à faire communiquer les « applications engines » (APE) avec le modem du mobile. HSI permet de multiplexer jusqu’à 16 canaux avec des latences faibles et une communication bidirectionnelle simultanée (full‐duplex).

Pour l’instant, aucun pilote n’utilise ce nouveau bus série, mais Carlos a indiqué qu’il travaillait sur le support d’une carte TI OMAP. D’autres développeurs ont manifesté leur intérêt auprès de Linus afin qu’il accepte ces patches (Several people piped up to say “yeah, we want this”).

Sous‐système remoteproc

Les systèmes complets sur une puce (SoC) contiennent souvent des cœurs de calcul très hétérogènes. Si l’on regarde par exemple le SoC OMAP 4 de Texas Instrument, on constate qu’il est constitué de deux processeurs Cortex-A9, de deux processeurs Cortex-M3 et d’un DSP de type C64x.
Comment faire dialoguer le plus proprement et le plus simplement possible ces divers cœurs de calcul ?

C’est ici qu’entrent en scène le nouveau sous‐système remoteproc et le mode de communication rpmsg qui ont été introduits dans le noyau 3.4.
Le sous‐système remoteproc permet au processeur principal de contrôler plus simplement les divers processeurs hétérogènes qui existent sur la puce SoC. C’est une sorte de couche d’abstraction du matériel, puisqu’il n’est plus besoin d’avoir des pilotes spécifiques pour gérer l’allumage (rproc_boot) ou l’extinction (rproc_shutdown) de ces processeurs spécifiques.
En plus de cette simplification qu’apporte remoteproc (voir la documentation), le bus rpmsg intégré permet au pilotes noyau de communiquer facilement avec les cœurs hétérogènes via une interface de type virtio. Un pilote d’exemple utilisant le bus rpmsg a été écrit par Ohad Ben-Cohen, afin de faciliter le travail des futurs utilisateurs.

Le résultat net de ces changements c’est que les SoC peuvent maintenant disposer d’un sous‐système générique de contrôle et de communication entre leurs divers cœurs hétérogènes de calcul. Au lieu d’avoir une prolifération de pilotes variés, il suffira maintenant d’utiliser remoteproc, en ajoutant juste un peu de code bas niveau spécifique à la plate‐forme.

Chargement retardé des pilotes

Un mécanisme amélioré de chargement des pilotes lors du démarrage a été ajouté dans ce nouveau noyau 3.4.
Dans les machines modernes, les périphériques sont devenus très complexes avec souvent plusieurs blocs fonctionnels interconnectés. L’ennui, c’est que dans ces configurations, il devient très difficile de déterminer l’ordre dans lequel les pilotes respectifs doivent être démarrés.
Grant Likely, l’auteur du patch, décrit ainsi le problème :

Une « carte son » typique consiste en plusieurs périphériques : un ou plusieurs blocs _codecs (souvent attachés via I²C ou SPI), un bus son (souvent I²C), un contrôleur DMA et une certaine quantité de code spécifique à la machine/architecture afin de tenir tout ça ensemble._
À l’heure actuelle, le code du noyau doit faire une vraie gymnastique afin d’enregistrer tous ces composants dans la couche son, et le pilote qui « tient tout ensemble » doit attendre que tous les autres pilotes soient chargés.

On voit donc qu’il s’agit là d’un problème de gestion des dépendances. Un pilote ne peut pas être chargé tant que les pilotes des autres composants ne sont pas déjà chargés. La solution semble donc simple : il suffit de déclarer une relation de dépendance entre les pilotes, comme on le fait pour les diverses options dans les fichiers Kconfig de Linux.
Le problème c’est que cette solution consistant à déclarer les dépendances ne marche pas dans le cas soulevé par Grant Likely et qui concerne les périphériques ayant plusieurs blocs fonctionnels interconnectés :

Considérez le cas où un pilote A dépend d’une ressource GPIO qui est apportée par un pilote B. En théorie, il faudrait indiquer que le pilote A dépend du pilote B, mais, en fait, le pilote A n’a aucun moyen de savoir de quel pilote B il s’agit, puisqu’il est différent pour chaque système.

Ces « périphériques » ne sont plus vraiment des entités matérielles bien distinctes. Il sont formés à partir de nombreux composants séparés au niveau matériel et ne sont réunis que par une « glu » logicielle. La conséquence, c’est que le noyau Linux n’a aucun moyen de savoir quelles sont les dépendances entre ces composants tant que ceux‐ci n’ont pas commencé à dialoguer.
Alors, comme dirait Lénine, que faire ?

La solution de Grant Likely n’est pas d’une élégance absolue, mais elle constitue un progrès indéniable par rapport à la très vilaine collection de bidouilles qui est utilisée actuellement. Le patch « driver probe deferral mechanism » permet tout simplement à un pilote de signaler qu’il n’a pas toutes les ressources nécessaires à son bon fonctionnement, et que son chargement doit être retardé afin d’être tenté à nouveau plus tard.
Par exemple, un pilote SDHCI peut avoir besoin de la collaboration d’un contrôleur I²C GPIO avant de pouvoir fonctionner correctement.
Si le pilote du contrôleur est déjà disponible lors du chargement du pilote SDHCI, alors tout se passe bien et on ne change rien au comportement précédent. En revanche, si le pilote du contrôleur I²C n’a pas encore été chargé, alors un message -EPROBE_DEFER sera envoyé pour signaler le problème, et le pilote SDHCI sera mis dans une liste d’attente (pending list). À chaque chargement réussi d’un pilote, le ou les pilotes en attente seront testés de nouveau pour voir si leurs dépendances sont satisfaites.
Comme indiqué dans le message d’annonce sur la LKML, c’est une approche « low‐tech », mais qui a l’avantage d’être simple et de fonctionner correctement.

Améliorations dans Perf

L’outil de traçage intégré dans le noyau, perf, a été mis à jour avec de nombreuses nouvelles fonctions.
Tout d’abord, les fonctions top, stat et record peuvent maintenant examiner des groupes de threads ou de processus. Il suffit de fournir la liste des numéros de processus (PID) séparés par une virgule de cette façon : perf top -p 21483,21485. On peut également filtrer par utilisateur avec l’option --uid. Pour que perf se contente d’afficher les tâches tournant sous mon utilisateur, il suffira donc de faire un petit perf top --uid patrick.

Une autre nouveauté est la possibilité de faire du profilage de précision au sujet des branches de code exécutées par le processeur. Cette fonction se base sur un module récent des processeurs Intel, le LBR (pour Last Branch Record).
D’après les explications présentes dans le message d’Ingo Molnar, il suffit d’activer la fonction avec perf record -b pour ensuite avoir la liste des branches qui sont exécutées le plus souvent par le processeur.

Enfin, la fonction report de perf dispose maintenant d’une interface graphique basique en GTK. Elle manque encore un peu de fignolage puisque, entre autres, il n’est pas possible de profiler un système KVM invité et qu’il n’y a pas de tri des colonnes, ni de code couleur pour les pourcentages. C’est toutefois un ajout bienvenu et qui va s’étoffer dans les versions suivantes du noyau. Le patch a été écrit par Pekka Enberg et la fonction s’active avec perf report --gtk.
Bien entendu, c’est une occasion unique et inespérée d’ajouter pour la première fois une nimage une copie d’écran dans une dépêche noyau :

perf report

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.4, le site LWN a publié son traditionnel article récapitulatif.

En termes de patches, le total s’établit à 10 734 (au 11 mai), alors qu’il était de 10 449 pour le noyau précédent. Ce sont 1 271 développeurs différents qui ont contribué au moins un patch dans ce cycle et, comme la dernière fois, c’est Mark Brown qui est en tête de liste avec 284 patches.

Si l’on classe les développeurs non plus en termes de patches mais en termes de lignes modifiées, alors c’est Joe Perches qui occupe la première place. Il faut dire que Joe s’est attaqué à la remise en ordre du style de codage de nombreux fichiers, afin qu’ils respectent les conventions Linux. On trouve, parmi de nombreux autres, ce monstro‐patch de 10 000 lignes pour corriger les espaces et passer l’épreuve de checkpatch sans générer d’alertes : 314 files changed, 50359 insertions(+), 50455 deletions(-).
C’est un travail ingrat, mais qui est incontestablement utile, puisqu’il apporte de l’uniformité dans le code source du noyau.

Enfin, un coup d’œil sur le classement des entreprises montre une nouveauté assez étonnante. En effet, pour la toute première fois, Red Hat abandonne sa première place au profit d’Intel (seulement 960 patches contre 1 138 pour la firme de Santa Clara). Linux n’était pas menacé par la monoculture, mais c’est toujours réjouissant de voir que le classement des top contributeurs évolue.
Red Hat garde toutefois sa prééminence en termes de tags « Signed-off », parce qu’elle emploie de nombreux lieutenants de Linus.

  • # Petites coquilles

    Posté par . Évalué à  3 . Dernière modification : le 21/05/12 à 10:53

    Encore bravo pour cette dépêche, toujours aussi passionnante à lire !
    Bon, passées les félicitations, je me dois de signaler quelques coquilles…

    il y a encore quatre demandes de merge dans ma boîte mail qui sont en attente et que je vais (probablement) les inclure

    Ou alors, c'est le "que" qu'il faut virer, mais les 2 ensemble, c'est redondant ou boulière

    Cela dit, je pense que c'était utile
    Le découpage de asm/system.h […] a peut-être été douloureusex

    • [^] # Re: Petites coquilles

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

      Dans le paragraphe dm-verity il manque aussi un s à
      (voir cet exemple avec les martphones OMAP 4)

      Et encore merci pour cette passionnante dépêche.

      • [^] # Re: Petites coquilles

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

        Corrigées. Merci à vous deux.

        • [^] # Re: Petites coquilles

          Posté par . Évalué à  2 .

          Ted a également proposé de retirer les options bsddf et bsdminix qui conduisent l'outil df à se comporter comme sous BSD ou MINIX… mais les cris d'orfraie sur la LKML l'ont finalement dissuadé.

          Options bsddf et minixdf je pense.

          • [^] # Re: Petites coquilles

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

            Bien vu. C'est corrigé.

            • [^] # Re: Petites coquilles

              Posté par . Évalué à  3 .

              Et aussi :

              Ted T'so, qui peste depuis plusieurs mois devant le nombre d'options présentes dans ext4 […]

              C'est "Ted Ts'o".

              • [^] # Re: Petites coquilles

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

                Merci, c'est corrigé.

                • [^] # Re: Petites coquilles

                  Posté par . Évalué à  2 .

                  Dans le paragraphe IRQ Mapping :

                  Auparavant c'était c'étaient les fonctions irq_alloc_desc et irq_free_desc qui étaient utilisées afin d'éviter les collisions dans les assignations des numéros des interruptions.

    • [^] # Re: Petites coquilles

      Posté par . Évalué à  4 .

      Il manque les tag sur la dépêche…d'ailleurs ils manquent souvent sur les dépêches concernant le noyau, ce qui ne facilite pas les recherche.

    • [^] # Re: Petites coquilles

      Posté par . Évalué à  5 .

      oui, c'est la grande classique qu'il vaut mieux éviter puisqu'elle est si évidente, mais là c'est vraiment … Surtout la partie sur YAMA, merci d'avoir repris l'historique pour (nous) permettre (aux lecteurs) d'avoir une chronologie des évolutions, c'est vraiment remarquable. Et bien meilleur que les dépêches anglo-saxonnes.

      à propos de x86 dans l'embarqué, il y a des matériels qui commencent à devenir bien sérieux (intéressants) même pour le grand public. 7watts pour tout ça, arm n'a qu'à "bien se tenir", si cela continue!

    • [^] # Re: Petites coquilles

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

      La couche device-mapper du noyau 3.4 accueille un nouveau module nommée dm-verity

      nommé, sans e à la fin.

      Ensuite, la vérification des hashs se fait seulement à la demande, quand le noyau à besoin de réellement accéder aux blocs sous-jacents

      a besoin.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # dm-verity

    Posté par . Évalué à  4 .

    Serait-il possible de créer un module noyau qui remplace dm-verity et se contente de donner la bonne réponse ?

    • [^] # Re: dm-verity

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

      Genre echo 42 ?

      Prochainement, je vous proposerais peut-être un commentaire constructif.

    • [^] # Re: dm-verity

      Posté par . Évalué à  6 .

      Il y avait la yes-card, et maintenant tu voudrais un yes-kernel ?

    • [^] # Re: dm-verity

      Posté par . Évalué à  4 .

      Deux possibilités:
      -soit le noyau est sur le disque et tu peux le modifier entre deux reboots lorsque l'utilisateur n'est pas devant le PC.
      -soit le noyau est, comme le dis l'article, sur une clé USB "sécurisée" qu'un attaquant ne pourras jamais obtenir, et donc il ne pourra pas charger ton module pirate, car il ne sera pas intègre…

      Dans le premier cas, tu es toujours perdant, sauf à utiliser une puce TPM, et la mesure d'intégrité etc…
      Dans le second cas, tu t'astreins à surveiller 24/24 ta clé USB. C'est certe plus petit qu'un PC, mais à mon avis, les risques sont les mêmes qu'un PC. Un cas d'usage était: comment fais tu lorsque tu vas à la piscine?

      • [^] # Re: dm-verity

        Posté par . Évalué à  2 .

        Une clé USB peut survivre à un lavage en machine (expérience involontaire), donc, à la piscine, ça doit passer dans le slip :-)

        • [^] # Re: dm-verity

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

          Elle peut même survivre à plusieurs lavages.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: dm-verity

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

            Elle peut même survivre à plusieurs lavages.

            Et si tu as des photos dedans? les couleurs se délavent-elles?

            ⚓ À g'Auch TOUTE! http://agauch.fr

            • [^] # Re: dm-verity

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

              Je n'ai pas fait attention, mais je peux garantir que la coloration du code source est identique. Par contre, j'ai l'impression que l'essorage fragmente les fichiers.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: dm-verity

          Posté par . Évalué à  9 .

          Si elle doit aller dans le slip, la question n'est plus si elle peut survivre à un lavage mais à un lavement.

          (j'ai honte)

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: dm-verity

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

      A titre perso, je ne vois pas qui ce genre de mesure dérange, vis-à-vis de Netflix en particulier:

      • Soit quelqu'un décide de ne pas "rooter" son terminal et de payer son abonnement à Netflix,
      • Soit il décide de rooter son terminal. Dans ce cas, Netflix ne marche plus, donc il arrêtera de payer Netflix, et ira, fort logiquement, tipiaker le contenu.

      Le seul perdant dans cette histoire c'est Netflix: Libre à lui de refuser de prendre des clients. Peut-être que c'est une perte acceptable pour eux face au risque de ne pas avoir l'aval des studios, je ne sais pas. Mais c'est un choix de LEUR part, non du client final.

      Moi je serais très intéressé par prendre Netflix lorsque ce sera disponible en France. Mais bien sur, je vérifierais, avant, que ça marche sur MES appareils dans la configuration que J'AI choisi. Si ça ne marche pas…. je ne m'abonnerais pas, et continuerais comme actuellement où il n'existe de toute façon aucune offre.

      A coté de cela j'imagine très bien utiliser dm-verity pour mon usage personnel.

  • # migration ext4

    Posté par . Évalué à  1 .

    Il y a un autre moyen que le montage "journal=update" pour migrer de ext3 à ext4 ? Du genre avec tune2fs ?

    • [^] # Re: migration ext4

      Posté par . Évalué à  5 .

      Oui. En fait je ne connaissais pas journal=update et toutes mes partitions ont été converties avec tune2fs suivi d'un fsck.

    • [^] # Re: migration ext4

      Posté par . Évalué à  3 .

      Dans le temps, j'ai utilisé cette commande :

      tune2fs -O extents,uninit_bg,dir_index /dev/sda1
      
      

      Je ne saurais plus te dire si elle est encore efficace, ni la signification exacte des options.

  • # Llano enfin

    Posté par . Évalué à  4 .

    Côté AMD, on voit arriver la prise en charge des cartes Southern Islands (Radeon HD 7700, 7800 et 7900) ainsi que des processeurs Fusion de type Trinity. Les cartes Northern Islands reçoivent des patchs écrits par Jérome Glisse et permettant la prise en charge du tiling 2D.
    Pour avoir une idée de la complexité du travail des développeurs de pilotes GPU, vous pouvez d'ailleurs aller lire ce post de Jérome dans lequel il raconte la difficile traque d'un bug affectant la sortie VGA des puces Llano.

    Ah bonne nouvelle :)
    Est ce que cette correction de bug permettra à la sortie HDMI de fonctionner correctement aussi ?

    Sedullus dux et princeps Lemovicum occiditur

    • [^] # Re: Llano enfin

      Posté par . Évalué à  1 .

      Donc plus besoin d'utiliser les drivers proprio ? Surtout qu'a la dernière MAJ de Xorg j'ai du revenir en arrière -'

      • [^] # Re: Llano enfin

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

        Ici dual screen DVI + HDMI ne marche toujours pas sur llano A6-3650…

        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

        • [^] # Re: Llano enfin

          Posté par . Évalué à  4 .

          Tu ne peux brancher au maximum que 2 ecran sur un llano, c'est materiel. Meme si tu as 2 connecteur dvi et un connecteur hdmi cela ne veut pas dire que tu peux les utiliser tous en meme temps.

          Souvent le manuel de ta carte mere t'indique cette limitation.

    • [^] # Re: Llano enfin

      Posté par . Évalué à  4 .

      Le HDMI fonctionne pour bcp de gens. Si tu as un probleme faut ouvrir un bug. Le probleme c'est que bcp gens pensent que lorsqu'il ont un probleme forcement le reste du monde a le meme. Qd il s'agit de GPU c'est rarement le cas, tellement de chose peuvent poser probleme que souvent seulement un faible pourcentage des personnes qui possede un meme GPU font fasse a un meme probleme.

      • [^] # Re: Llano enfin

        Posté par . Évalué à  3 .

        Oui, je comprends, en gros j'ai 2 expériences dans mon entourage avec Llano :

        • La première expérience sur Ubuntu : Les dernières versions d'Ubuntu ( depuis la 11.04 ) incluent kms par défaut à l'installation.
          Or, ces versions ne fonctionnent même pas en liveCD si on ne passe pas l'option " nomodeset " au démarrage du CD. Une fois Ubuntu installé, soit on reste en " nomodeset " en passant cette option à GRUB, soit on utilise les drivers proprios.
          Et tout fonctionne correctement. L'installation s'est faite il y a quelques mois, et les bug tracking étaient déjà pleins de ce problème. Donc j'ai pas ouvert de suivi. :)

        • La deuxième est toute récente, mais se base sur une Debian Stable. ( Pour mes parents ).

        Ils disposent d'un écran Samsung 23.6" 1920x1080, cet écran ne dispose que d'une entrée VGA et une entrée HDMI. Remarque que j'aurais pu tester avec une autre écran disposant d'une entrée DVI . Mais je ne l'ai pas fait.
        Après installation de base, aussi bien sur le VGA que sur le HDMI les résolutions natives de l'écran ne sont pas détectées. Sur le VGA, l'affichage se faisait en 1280x1024, et sur le HDMI, l'affichage se faisait en 800x600.
        Rien de transcendant en WW ou EE sur Xorg.0.log .

        J'ai pas essayé de forcer un Xorg.conf, j'ai juste installé le paquet non-free du microcode, et là, je me retrouve en 1600x1200 par la sortie VGA, et une résolution aléatoire plus basse sur le HDMI. Et le 1920x1080 , résolution " full HD " , n'est pas proposé.

        Avant d'ouvrir un Bug Track, j'aimerais approfondir les tests avec un autre écran ( qui fonctionne parfaitement sur du HD4200 - -880GX-890GX chip intégré aux cartes mères AM2+ )
        mais qui dispose d'entrées VGA et DVI. ( et toujours en 1920x1080 ). Et satisfaire ma curiosité sur les versions des différents logiciels présents sur Debian Stable. :)

        Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: Llano enfin

          Posté par . Évalué à  2 .

          Avant d'ouvrir un bug test un livecd comme fedora 17 ou alors ubuntu 12.04. Malheureusement debian stable est problematique lorsqu'il s'agit du support hw, les drivers progressant vite et changeant enormement, debian stable a tendance a avoir bcp de code trop vieux.

          • [^] # Re: Llano enfin

            Posté par . Évalué à  2 .

            Ah oui, un liveCD récent devrait répondre à la question. Je ferais ça ce week end. :)

            Sedullus dux et princeps Lemovicum occiditur

      • [^] # Re: Llano enfin

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

        C'est un peu hors sujet mais je me demandais s'il était possible d'aider les développeurs de pilotes graphiques sans rien connaître au domaine.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Llano enfin

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

          Je sais que les développeurs de nouveau ont mis sur leur site qu'ils acceptaient des modèles de cartes graphiques par don pour améliorer le support de certaines cartes.

          Puis il y a toujours le classique de remonter les bogues éventuels avec des rapports d'erreur (mais ils peuvent signaler els infos qui leur sont nécessaires).

          Sans rien connaitre au domaine il est donc facile de les aider, cela demande de l'argent ou un peu de temps. Il faut partir du principe que le support d'une carte ne peut pas s'améliorer par magie et qu'il faut des informations ou un accès à la carte elle même…

          • [^] # Re: Llano enfin

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

            Le problème pour les rapports de bugs, c'est que je n'ai pas de problème à part des performances qui peuvent être mauvaises (mais c'est connu) ou OpenGl x.y qui n'est pas supporté (mais c'est aussi connu). De plus, j'espérais plus les décharger de boulot plutôt que leur en donner plus.

            En fait, j'imaginais plus une réponse du genre : "Quelle est la forme qui apparaît à l'écran quand vous cliquez le bouton droit avec la main gauche tout en faisant le poirier et en soufflant sur la carte graphique ?" ou "Pas besoin d'être un expert, vous pouvez déjà essayer d'écrire du code pour tel truc".

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Participer à "nouveau"

              Posté par . Évalué à  2 .

              Moi aussi, je serais ravi d'aider sans nécessairement devenir contributeur au projet. Par exemple en exécutant des scripts de test sur mon matériel et en envoyant des rapports de bogues clairs (et en attendant que le boulot se fasse).

              Pour le reste, je ne sais pas si j'ai les compétences mais si je ne les ai pas, elles s'acquièrent, c'est surtout une question de temps et (donc) de volonté.

              Pour répondre à ta question, voilà ce qui est écrit sur le site de nouveau :

              • Utiliser nouveau au quotidien en faisant des mises à jour régulières et remonter les bogues.

              • Répondre aux besoins de tests spécifiques

              • Une TODO list avec des tâches ingrates de communication / documentation, mais aussi des activités de développement qui doivent commencer à demander plus d'investissement.

              Au passage, j'apprends que nouveau ne gère pas l'accélération OpenGL alors que j'étais persuadé du contraire. Par exemple pour Teeworlds qui utilise OpenGL, ça fonctionne. Je dois faire de grosses confusions, ce qui relativise pas mal les capacité du premier quidam venu à participer à la documentation… (problèmes récurrents dans pas mal de projet où les développeurs n'ont pas le temps de tout faire).

              • [^] # Re: Participer à "nouveau"

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

                Le problème c'est que je n'ai pas du nvidia mais du amd, c'est moyen pour contribuer à nouveau ;)

                Pour l'Opengl, si je me souviens bien, ce n'est pas encore activé par défaut mais certaines distrib le font déjà.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Participer à "nouveau"

                  Posté par . Évalué à  4 .

                  Si tu t'y connais en opengl tu peux toujours essayer de faire une suite de test. La suite de test de webgl de mozilla à trouver plein de soucis dans les drivers. Ensuite, il suffit de pondre un rapport de test avec la configuration précise.

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                • [^] # Re: Participer à "nouveau"

                  Posté par . Évalué à  1 .

                  Le problème c'est que je n'ai pas du nvidia mais du amd, c'est moyen pour contribuer à nouveau

                  Oui, j'avais vu que tu ne l'avais pas spécifié. Je répondais en même temps au commentaire de Renaud au-dessus, et je me suis dit que ça pourrait être utile à quelqu'un d'autre.

                  Pour l'Opengl, si je me souviens bien, ce n'est pas encore activé par défaut mais certaines distrib le font déjà.

                  En fait, j'utilise le paquet libgl1-mesa-dri-experimental, ça ne fonctionnait pas avec le paquet par défaut. Donc le fin mot de l'histoire, c'est que ça fonctionne, mais expérimentalement, donc ce n'est pas "supported". Ceci dit, au quotidien, chez moi, c'est satisfaisant.

            • [^] # Re: Llano enfin

              Posté par . Évalué à  6 .

              Sans être un expert, mais en sachant programmer en C, j'ai corrigé 3 bugs pour le pilote gma500 (poulsbo) : le suspend/resume qui ne plantait, le curseur matériel, et des freezes d'écran qui venaient de bugs matériels.

              Il faut se mettre dedans, cela demande des efforts, mais ça reste accessible pour qui connaît le C.

              Je pense qu'un bug rapporté par quelqu'un qui a une bonne vision du dev peut être beaucoup plus riche qu'un bug rapporté par un utilisateur final classique, donc n'hésite pas à compléter un bug déjà existant également, en rajoutant des logs, des précisions, …

              Après, si tu n'as pas de problème, ça va être difficile de les corriger ;) Mais dans ce cas, tu peux aussi te mettre à tester les rc au fur et à mesure et reporter les régressions.

              Ou t'inscrire sur la ML dri-devel et tester les patchs qui concernent ta carte graphique.

    • [^] # Re: Llano enfin

      Posté par . Évalué à  3 . Dernière modification : le 22/05/12 à 01:02

      Est ce que cette correction de bug permettra à la sortie HDMI de fonctionner correctement aussi ?

      Pour un récap des fonctionnalités supportées par Radeon :

      http://www.x.org/wiki/RadeonFeature

  • # Gloire

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

    C'est la gloire pour patrick_g<, il est cité comme source de l'article de PC Inpact.

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Gloire

      Posté par . Évalué à  4 .

      Notons d'ailleurs que PC Inpact a illustré cet article par une capture d'écran Ubuntu. Encore une preuve que Linux == Ubuntu.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Gloire

        Posté par . Évalué à  1 .

        Tu veux dire que GNU/Linux == Debian/Ubuntu ?

    • [^] # Re: Gloire

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

      chez Clubic aussi, si c'est pas de la monoculture ça !

      • [^] # Re: Gloire

        Posté par . Évalué à  1 .

        comme l'explique notre confrère LinuxFr.org.

        Beurk…

        Il aurait été plus correcte d’écrire : « comme l’explique nos confrères sur LinuxFR.org ». Ou bien : « comme l’explique l’article publié sur LinuxFR.org ».

        De même :

        deux mois et deux jours seulement après la version précédente, conformément à l'accélération du rythme de développement.

        Ça fait combien de temps qu’il a été décidé de modifier le rythme de sortie des versions ?

        • [^] # Re: Gloire

          Posté par . Évalué à  2 .

          Ça fait combien de temps qu’il a été décidé de modifier le rythme de sortie des versions ?

          Je crois que je l'ai toujours connu ainsi, donc avant le 2.6.19.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Gloire

          Posté par (page perso) . Évalué à  2 . Dernière modification : le 22/05/12 à 11:56

          "comme l'explique notre confrère LinuxFr.org"
          Ils ont pas dû remarquer le caractère collaboratif du site je pense…

          • [^] # Re: Gloire

            Posté par . Évalué à  1 .

            Collabora-quoi ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # 3.4 pas encore promu stable ?

    Posté par . Évalué à  1 . Dernière modification : le 21/05/12 à 15:58

    Sur kernel.org, à l'heure de ce post, le 3.4 est uniquement proposé sous forme de patch, avec la dénomination "mainline". Le stable en full-source est 3.3.6
    J'ai loupe un passage sur le versionning noyau ?

    Bon, j'ai pas encore eu le temps de lire la dépêche, donc désolé si c'est expliqué dedans.

    • [^] # Re: 3.4 pas encore promu stable ?

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

      Il y a toujours un délai entre l'annonce officielle par Linus et la mise à jour sur kernel.org.

      • [^] # Re: 3.4 pas encore promu stable ?

        Posté par . Évalué à  2 .

        Je comprends/sais, mais le délai (ou plutôt l'écart par rapport à la publication de la dépêche sur DLFP) me parait sensiblement plus grand que d'habitude.

        En tous cas, merci, pour la réponse, et pour la dépêche bien-sûr (j'espère que ça sera calme au boulot demain!)

        • [^] # Re: 3.4 pas encore promu stable ?

          Posté par . Évalué à  9 .

          Non c'est déjà arrivé. patrick est plus rapide que les mainteneurs de kernel.org :)

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # YAMA

    Posté par . Évalué à  6 .

    Ce n'est pas la première fois que patrick_g nous relate une discussion qui s'éternise sur des choix techniques. Ça m'attriste toujours j'ai l'impression que le bazar est très loin derrière nous et que les hackers du noyau ont construit une jolie cathédrale. À peu près à chaque fois que quelque chose de nouveau arrive en sécurité, il faut compter 18 à 24 mois pour le voir intégré parce qu'au moins 2 hackers de renom se prennent le choux pour savoir si une vision ou une autre est là mieux.

    Je comprends leur intérêt pour la qualité d'un code qui a 20 ans et qui risque bien de rester encore un paquet d'années, mais souvent la question semble être plus proche de querelles de clocher et/ou idéologiques que des arguments fondés sur de la technique et réellement objectif. C'est d'autant plus criant que l'on voit ici que YAMA était prêt il y a un peu moins de 2 ans !

    Ce qui est dommage c'est que pour pouvoir intégrer quelque chose qui n'est pas consensuel, il faut non seulement avoir un code de qualité, mais aussi avoir le cuir épais et la tête dur. Pour quelques anecdotes comme celle là combien de fonctionnalités ne sont jamais intégré faute de s'être fait écharpé par la LKML ?


    Personnellement je suis un peu dégouté je viens de passer toutes mes installations à 3.3.6 ce week end…

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: YAMA

      Posté par . Évalué à  10 .

      Je ne vois pas où est le problème.
      De façon générale, quand on intègre une nouvelle pièce, je ne vois comment on pourrait éliminer le débat technique. Il est normal que la communauté des développeurs du noyau critique ou soutienne un patch intrusif. Et convaincre un groupe hétéroclite est souvent difficile. Cela m'inquiéterait beaucoup si un module de ce genre pouvait entrer dans Linux comme une lettre à la poste, juste avec l'accord d'un ou deux mandataires Linux.
      Dans ce cas particulier, je vois encore moins pourquoi ils se seraient pressés. Pour les distributions ou les installations à fort besoin en sécurité, SELinux et consorts sont là et YAMA n'apporte alors rien de neuf. Pour les autres, le patch était dispo s'ils voulaient ce petit surplus de sécurité, et certaines distrib ont fait ce choix sans attendre l'intégration officielle.

      Personnellement je suis un peu dégouté je viens de passer toutes mes installations à 3.3.6 ce week end…

      Je suis peut-être parano, mais je ne passe jamais aux nouvelles versions majeures du noyau. En tout cas pas sur les machines dont la stabilité est importante pour moi. Je crois que la 3.3.6 est plus fiable que la 3.4 dont les nouvelles fonctionnalités n'ont pas été testées à très grande échelle. Alors si aucune des nouveautés ne me semble immédiatement utile, en particulier en terme de support matériel, j'attends que de nouvelles versions mineures sortent.

      • [^] # Re: YAMA

        Posté par . Évalué à  3 .

        De façon générale, quand on intègre une nouvelle pièce, je ne vois comment on pourrait éliminer le débat technique. Il est normal que la communauté des développeurs du noyau critique ou soutienne un patch intrusif. Et convaincre un groupe hétéroclite est souvent difficile. Cela m'inquiéterait beaucoup si un module de ce genre pouvait entrer dans Linux comme une lettre à la poste, juste avec l'accord d'un ou deux mandataires Linux.

        Si le débat était toujours réellement technique oui, mais souvent c'est vraiment quelque chose qui deviens philosophique (« selon moi ce type de code ne devrait pas être dans tel sous système (bon il se fait que je gère ce sous-sytème est que, peut être, je n'ai tout simplement pas envie d'avoir la charge ce code en plus »). Ça n'est pas une critique contre les hackers en particuliers (que j'admire sous bien des points), mais il me semble ressortir de certaines de ces discussions que des fois ben les réactions sont plus épidermiques que constructives (c'est pareil en entreprise, hein).

        Personnellement je suis un peu dégouté je viens de passer toutes mes installations à 3.3.6 ce week end…

        Je suis peut-être parano, mais je ne passe jamais aux nouvelles versions majeures du noyau. En tout cas pas sur les machines dont la stabilité est importante pour moi. Je crois que la 3.3.6 est plus fiable que la 3.4 dont les nouvelles fonctionnalités n'ont pas été testées à très grande échelle. Alors si aucune des nouveautés ne me semble immédiatement utile, en particulier en terme de support matériel, j'attends que de nouvelles versions mineures sortent.

        Je ne parle que de machine personnelle si un noyau crash je reboot sur la version précédente sans me poser plus de question.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: YAMA

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

      Cela me semble au contraire plutôt sain: il vaux mieux être sur de son coup, quitte à passer pas mal de temps à peser le pour et le contre et à évaluer l'impact sur d'autres sous-systèmes, les possibles évolutions futures, etc

      Dans les modestes projets open source que je gère, je dois dire que je fait de même (à mon échelle): je traine pas mal des pieds avant d'intégrer un changement qui modifie les interfaces présentés à l'extérieur ou bien le comportement du système. Ceci afin d'éviter le syndrome du bateau ivre, un coup d'un côté, puis finalement de l'autre, puis retour au premier, etc

      Mathias

      • [^] # Re: YAMA

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

        Deux petites remarques.
        La première va dans ton sens puisque je pense également qu'il est sain de peser longuement de pour et le contre avant d'intégrer des nouveautés. Linus a dit à plusieurs reprises qu'il fallait savoir dire non plus souvent et ne pas inclure tous les patchs qui sont soumis. Le fait qu'il y ait une barrière importante à l'entrée est donc assez positif puisque cela permet de jauger de la motivation et de la volonté de maintenance à long terme de ceux qui proposent une nouvelle fonction.
        En plus les BSD reprochent assez souvent au monde Linux ce "syndrome du bateau ivre" donc il vaut mieux soigneusement réfléchir avant d'accepter un truc intrusif.

        D'un autre côté, pour aller cette fois dans le sens de Michel, c'est un fait que le sujet de la sécurité dans Linux est assez spécifique. Le niveau de consensus technique entre les développeurs est assez faible et il n'est pas rare de voir les tenants des différents modules de sécurité se sniper entre eux. LSM n'est qu'un palliatif qui leur permet de cohabiter dans le noyau mais certains ne seraient pas fâché de voir leur module devenir la solution unique de référence.
        C'est donc dommage de les voir s'écharper sur la LKML sans que certains sujets n'avancent. Il me semble que depuis un ou deux ans il y a quand même du progrès et les sommets sur la sécurité ont certainement aidé à une meilleure compréhension mutuelle.

        • [^] # Re: YAMA

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

          Tu veux dire que les mecs qui bossent dans le domaine de la sécurité sont des sociopathes avec un ego surdimensionné ?

          <ironie>Ça serait bien la première fois qu'on vois ça </ironie>

    • [^] # Re: YAMA

      Posté par . Évalué à  2 .

      Personnellement, ce qui m'étonne c'est au contraire le décalage entre "Oui, on va accepter telle option de sécurité improbable pour le cas où quelqu'un arrive à lire tes mails en piratant le driver de ton clavier via un javascript", et "boarf, dm-verity permet à un tiers de priver l'utilisateur de tout contrôle de sa machine, mais on va quand même l'intégrer". Le premier danger, objectivement, pour les utilisateurs de Linux sur mobile, c'est Google ou Netflix, pas le pirate improbable.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: YAMA

        Posté par . Évalué à  4 .

        Sauf qu'à si j'ai compris dm-verify ne permet pas à Google et consort de pirater ta machine, seulement de vérifier que l'OS installé est bien celui d'origine.

        Je ne pense pas qu'on puisse comparer une fonctionnalité et la correction d'une faille.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: YAMA

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

          Puis ça peut aussi servir dans les secteurs critiques comme tout ce qui touche à la défense ou confidentialité industrielle. Ces machines là sont souvent attaquées par des membres internes ou externes à l'organisation car les informations contenues dans ce genre d'endroit peut rapporter gros à la concurrence.

          C'est sûr que ce n'est pas aujourd'hui que la menace existe vraiment pour le quidam moyen…

          • [^] # Re: YAMA

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

            En plus, ca pourrait servir aux machines a voter… ;-)

      • [^] # Re: YAMA

        Posté par . Évalué à  3 .

        Le premier danger, objectivement, pour les utilisateurs de Linux sur mobile, c'est Google ou Netflix, pas le pirate improbable.

        C'est qui les utilisateurs de linux ? Parce que si tu pense a une utilisation de bureau c'est loin d'être l'unique cible de linux et ce n'est pas son utilisation la plus répandue.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: YAMA

          Posté par . Évalué à  5 .

          Je pense à l'utilisation où les gens n'ont pas forcément conscience de la présence du noyau Linux : matériel mobile (téléphone, tablettes), boîtiers multimédia, machinbox, consoles de jeux..

          J'ai l'impression d'une tendance au verrouillage et à la non-bidouillabilité volontaire de ce type de périphériques, alors que la présence de Linux devrait au contraire être une opportunité pour permettre des modifications. Du coup, l'acceptation passive de technologies de contrôle dans le noyau m'inquiète. Je trouverais préférable d'engager un bras de fer avec ces industries, en faisant en sorte que l'usage de Linux implique de toute façon un minimum de libertés côté utilisateur, et leur laisser le choix entre réinventer la roue, ou profiter de la puissance de Linux mais ne pas faire les fascistes.

          Quand je dis "fasciste" c'est à ce genre de décisions que je pense, par exemple :

          http://seclists.org/fulldisclosure/2008/Nov/506

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: YAMA

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

            Le vrai problème c'est que des gens achètent ces appareils:

            "Quand on pense qu'il suffirait que les gens n'achètent pas pour que ça ne se vende pas" !

            C'est aussi une forme de consommation effrénée: Ces appareils sont conçus rapidement, pensés en "one-shot", avec une durée de vie réduite: Si les gens commencent à pouvoir le réparer, ou continuer à l'utiliser après que la génération d'après soit sortie, c'est une "perte" pour le constructeur… C'est typiquement le cas des machin Apple (bien qu'eux misent plutôt sur d'autres leviers pour exacerber l'envie d'achat).

            Je pense qu'il y a aussi de ça. Et effectivement c'est néfaste.

            Mais de plus en plus on commence à trouver des appareils, asiatique il est vrai, avec une vrai politique d'ouverture (ou, au moins, de non fermeture) d'une qualité qui est bien meilleure qu'il y a quelques années.
            A mon avis il va arriver un moment où ça va basculer: A un moment, les gens vont plus avoir envie d'acheter une 5ème tablette en 5 ans - par manque de fric, par manque d'intérêt renouvelé.

            Il faut bien avouer que les gens qui installent un firmware modifié ou qui hackent leur matériel, c'est quelques % des acheteurs.

            C'est pas que dans l'informatique, d'ailleurs: Il y a 20 ans tout conducteur savait plus ou moins faire les niveaux et la vidange de sa caisse, et changer une roue. Plus maintenant…. A mon avis c'est une forme de régression de société, cette perte de pragmatisme.

            • [^] # Re: YAMA

              Posté par . Évalué à  2 .

              C'est rare d'arriver à résumer la situation + la conclusion en ci peu de lignes. Bien joué !

              Difficile paradigme entre ces appareils qui font de plus en plus et sont simples à utiliser (pour ceux qui les achètent) mais qui permettent de faire de moins en moins et sont complexes à modifier (pour ceux qui me lisent).

              Cette consommation effrénée que tu cites ne sera pas arrêtée par le manque d'intérêt (doux rêveur), mais par le manque de ressources .. Et la il sera trop tard pour mettre en place une solution alternative, polyvalente, modulaire, maintenable, communautaire, … … …

              Ta remarque sur l'Asie (+ don't forget Africa) est sympa aussi, car c'est eux qui nous éclaireront vers le chemin à suivre, ou nous couleront s'ils suivent notre chemin … Wait & See … Euh, non , je veux dire Do&Teach ;-)

  • # comme les éclipses

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

    Enfin on va pouvoir aligner le n° de version du noyau avec celui de GNOME. Comme les éclipses, ça doit pas arriver si souvent…

  • # Coquille

    Posté par . Évalué à  1 .

    La situation est très simple. Soit vous me laissez mettre tout ça dans un module pour que les gens puisse

    puissent

  • # x32

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

    Je me demande si mon netbook Dell Mini 9 sous processeur 32 bits Intel Atom N270 bénéficierait de cette architecture ?

Suivre le flux des commentaires

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