Le noyau Linux 3.9 continue sa conquête de la plateforme ARM

Le noyau Linux 3.9 continue sa conquête de la plateforme ARM

18 SoC gérés pour l'instant

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

30/04/2013 4 minutes
51

Le noyau Linux 3.9 continue sa conquête de la plateforme ARM

Le noyau Linux continue sa progression rapide. Un peu de plus de deux mois après la version 3.8, qui s’était notablement affranchie de sa vieille compatibilité avec l’architecture i386, la mouture 3.9 propose diverses améliorations, en particulier le support d’ARM et de nouveaux pilotes graphiques.

noyau linux 3.9

Conquête de la plateforme ARM et pilotes graphiques 

L’un des principaux chantiers actuels pour le noyau Linux est de réaliser avec l’architecture ARM ce qui a été fait il y a de nombreuses années avec x86. La communauté souhaite en effet un noyau unique capable de gérer toutes les plateformes ARM, et elles sont nombreuses. À titre indicatif, le noyau 3.9 supporte 18 SoC, mais la route est encore longue. À terme, un noyau unique pourrait par exemple être réutilisé en l’état dans l’informatique embarquée, les smartphones, tablettes, etc. Notez également que la partie graphique des puces Tegra est maintenant mieux gérée.

 

La liste des améliorations de cette version 3.9 est relativement longue. À commencer par les pilotes graphiques. Du côté d’Intel, la réécriture du pilote est toujours en cours, mais le noyau 3.9 est déjà prêt pour les futures générations Haswell et Valley View. Côté NVIDIA, les nouveautés sont plus substantielles. Les ventilateurs de toutes les GeForce 6xxx à 9xxx peuvent ainsi être gérés automatiquement ou manuellement, et la température de la carte peut déclencher l’extinction du PC par sécurité. Toutes les cartes gèrent cette dernière possibilité, sauf  celles basées sur le G80 de NVIDIA qui devront attendre la version 3.10 du noyau. Enfin, pour AMD, les Radeon HD 8500 et 8600 sont prises en charge, de même que les futurs APU Richland.

Nombreuses corrections dans la gestion de l'IPv6 

Le système de fichiers Btrfs se retrouve amélioré une fois de plus. Dans la version 3.8 du noyau, ses performances étaient ainsi meilleures dans certains cas d’utilisation. Avec le nouveau noyau, il gagne la gestion des RAID 5 et 6.

 

Côté réseau, les nouveautés sont plus nombreuses. Le support du protocole IPv6 est ainsi amélioré en corrigeant plusieurs problèmes de sécurité dans le transit des données IPv6 à travers IPv4. L’implémentation des technologies 6rd et 6to4 permettait en théorie à un utilisateur malveillant de masquer la véritable provenance d’une attaque. Toujours pour IPv6, on signalera également la correction de problèmes liés au multicast, ainsi que la prise en charge du protocole par netconsole.

 

Du côté de Netfilter, on notera en particulier l’ajout de BPF, pour Berkeley Packet Filter. Il s’agit d’un filtre avancé proposant de nombreuses possibilités. En outre, ce nouveau filtré peut être verrouillé sur un socket en particulier afin qu’il ne puisse pas être supprimé. Il agit alors comme un ordonnanceur puisque plusieurs processus peuvent alors écouter sur le même port. Les demandes de connexions peuvent donc être gérées en parallèle, notamment dans le cas d’un processeur à cœurs multiples.

Virtualisation et améliorations diverses 

La virtualisation est également améliorée. Par exemple, KVM supporte officiellement l’architecture A15 d’ARM, mais Xen devra attendre la version 4.3 qui n’arrivera pas avant plusieurs mois. Notez également qu’il devient possible d’ajouter à chaud des processeurs et de la mémoire vive, même si la suppression n’est pas encore de la partie. Les pilotes VMCI vont permettre quant à eux une communication directe entre l’hyperviseur VMware et le système Linux invité.

 

Parmi les autres nouveautés, on citera en particulier la compatibilité avec les ZPODD (pour « zero power optical device drives »). Il s’agit de lecteurs optiques qui ont une consommation d’énergie quasi-nulle quand ils n’ont aucun média présent. La compression et la décompression LZO se veut quant à elle beaucoup plus rapide. Enfin, le travail sur le support de la gestion d’énergie ASPM continue.

 

Comme d’habitude, la nouvelle version du noyau va arriver progressivement dans les dépôts des différentes distributions Linux. Il suffira donc de s’armer d’un peu de patience si ce n’est pas votre cas actuellement. Les lecteurs intéressés pourront en outre obtenir plus de détails dans l'actualité consacrée au noyau par LinuxFR.org.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Conquête de la plateforme ARM et pilotes graphiques 

Fermer

Commentaires (51)


En voilà une nouvelle qu’elle est bonne!



C’est fou de voir le nombre de modifications/ajouts qui sont faits sur linux ces derniers temps.. aller les gars bon boulot, keep on going :) <img data-src=" />








Oulanos a écrit :



En voilà une nouvelle qu’elle est bonne!



C’est fou de voir le nombre de modifications/ajouts qui sont faits sur linux ces derniers temps.. aller les gars bon boulot, keep on going :) <img data-src=" />







En même temps on savait depuis la version 3.0 que le rythme serait élevé et régulier ;)



Ca reste quand même une version notable, du tout bon <img data-src=" />


Changements intéressants. Puisqu’on parle de pilotes, il me semblait que nVidia se décidait enfin à développer le support d’Optimus, mais j’imagine que ça sera pour une prochaine version…



D’ailleurs une question bête me taraude l’esprit : la version suivante sera-t-elle la 4.0, ou 3.10 ? Question hautement existentielle <img data-src=" />


3.10 ;)








Latios a écrit :



3.10 ;)





<img data-src=" />









Latios a écrit :



3.10 ;)





Merci ^_^



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?








Konrad a écrit :



Changements intéressants. Puisqu’on parle de pilotes, il me semblait que nVidia se décidait enfin à développer le support d’Optimus, mais j’imagine que ça sera pour une prochaine version…





c’est surtout que les pilotes developpes par nvidia ne sont pas dans le kernel <img data-src=" />



Je parie que Vmware sera encore à la traine sur le support de ce noyau.


Le screenshot qui illustre l’actu présente un site presque moins classe que la première page web <img data-src=" />



old school :)


J’ai hâte de pouvoir un jour prendre un kernel mainline et le faire booter sur une archi ARM comme je ferais sur un PC. J’ai de mauvais souvenirs notamment avec le N810 (RX-44) où il faut prendre un noyau spécifique, et encore arriver à le faire booter de façon stable c’est assez laborieux…








Aloyse57 a écrit :



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?







C’est déjà le cas. <img data-src=" />









Aloyse57 a écrit :



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?







Google et Samsung ayant déjà sorti un Chromebook ARM (à base de Linux), rien ne semble s’y opposer.



http://www.pcinpact.com/news/78341-le-chromebook-arm-samsung-arrive-en-france-a-…



Sans oublier les Raspberry Pi, à base d’architecture ARM, qui peuvent déjà faire tourner des distributions Linux avec environnements de bureau (par contre, vaut mieux oublier Gnome et KDE, vu les faibles ressources disponibles) XD









Aloyse57 a écrit :



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?







Déjà le cas, me semble que la plupart des environnements de bureau ont déjà été porté pour l’archi ARM.



Après, dans le monde de l’informatique et non de l’embarqué, c’est le X86 qui reste privilégié pour les mises à jours et nouveautés, ensuite c’est porté.









Aloyse57 a écrit :



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?







À peu près tous les desktops existants ont déjà leur version compilée pour ARM.



edit: :burned:









Nuggets a écrit :



Le screenshot qui illustre l’actu présente un site presque moins classe que la première page web <img data-src=" />



old school :)







Manque le logo (en texte) “Optimisé pour Lynx“ <img data-src=" />









Aloyse57 a écrit :



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?







Linux supporte déjà certains ARM, mais c’est un peu le bordel. Là ils font du ménage pour n’avoir qu’un seul code pour tous les chipsets ARM, comme c’est le cas pour l’architectur x86. Ça simplifie énormément la donne pour maintenir le code et pour porter des logiciels dessus par exemple



Merci pour vos réponses.

Questions suivantes, toujours dans une optique Linux :





  • Qu’en est-il des applis qui fonctionnent sur un desktop x86 ? Faut-il les recoder entièrement pour ARM ou fonctionnent-elles dans des espèces d’émulateurs ?

  • Peut-on créer des machines virtuelles x86 qui tournent sur ARM ?








Vivement le 3.14 !<img data-src=" />


Le 30/04/2013 à 15h 58

Pour ce qui est des pilotes graphiques Intel, il y a clairement du boulot à abattre, car c’est franchement le bordel et une véritable régression depuis la version 3.2.x !!! <img data-src=" />



C’est soit écran noir total, soit affichage brouillé, soit limitation au 1026x768 avec ma mobo GA-H77N-Wifi + Core i5… <img data-src=" />



Donc, faut jouer du xrandr pour avoir un affichage étendu, surtout au delà du 1280x800….



Et de ce que j’ai constaté, je suis loin d’être le seul dans la même situation…


Le 30/04/2013 à 16h 04







Aloyse57 a écrit :



Merci pour vos réponses.

Questions suivantes, toujours dans une optique Linux :





  • Qu’en est-il des applis qui fonctionnent sur un desktop x86 ? Faut-il les recoder entièrement pour ARM ou fonctionnent-elles dans des espèces d’émulateurs ?

  • Peut-on créer des machines virtuelles x86 qui tournent sur ARM ?







    Ça dépend du langage avec lequel il a été codé à la base…



    Si c’est du html5, pas de souci, sinon faudra probablement tout recoder… ^^



    Quand on voit déjà les problèmes de compatibilité entre Python 2 et 3.x, c’est pas un cadeau…









Aloyse57 a écrit :



Question d’ignare en Linux : est ce que cela signifie qu’il pourrait exister un desktop sur un ordi ARM similaire à celui sous x86 (Unify, Gnome, KDE, etc…) ?







Avec le temps, et si tous les ordinateurs avec CPU ARM ne sont pas verrouillé, oui.









Aloyse57 a écrit :





  • Qu’en est-il des applis qui fonctionnent sur un desktop x86 ? Faut-il les recoder entièrement pour ARM ou fonctionnent-elles dans des espèces d’émulateurs ?

  • Peut-on créer des machines virtuelles x86 qui tournent sur ARM ?







    la plupart des applis sont codées en c/c++, suffit de recompiler.

    pour l’émulation, je suppose qu’il y aurait moyen avec qemu, mais ça n’a sans doute pas grand intérêt à moins de vouloir faire tourner un windows XP sur ARM <img data-src=" />









Aloyse57 a écrit :



Merci pour vos réponses.

Questions suivantes, toujours dans une optique Linux :





  • Qu’en est-il des applis qui fonctionnent sur un desktop x86 ? Faut-il les recoder entièrement pour ARM ou fonctionnent-elles dans des espèces d’émulateurs ?

  • Peut-on créer des machines virtuelles x86 qui tournent sur ARM ?







    Les applis pour x86, si leur code est ouvert, sont portables mais ça peut demander du boulot. Beaucoup ont déjà été portées. Raspbian, la version de Debian pour Raspberry Pi, est complète et comprend donc (en option) Gnome, LibreOffice, Gimp etc. J’ai testé, ça s’installe, mais c’est inutilisable tellement ça rame. Par contre, Xfce et AbiWord ça va.



    Pour une machine virtuelle, si elle doit émuler en temps réelle chaque instruction machine, là aussi c’est toujours possible mais très lent. Et un processeur ARM n’est pas assez rapide pour cela, à moins de se contenter d’émuler un vieux 486.





Comme d’habitude, la nouvelle version du noyau va arriver progressivement dans les dépôts des différentes distributions Linux



<img data-src=" />



La nouvelle Debian Wheezy sort dans 1 semaine.<img data-src=" />



Avec un noyau 3.2<img data-src=" />








Aloyse57 a écrit :





  • Qu’en est-il des applis qui fonctionnent sur un desktop x86 ? Faut-il les recoder entièrement pour ARM ou fonctionnent-elles dans des espèces d’émulateurs ?





    Si ça n’est pas écrit avec les pieds et que ça n’utilise pas d’assembleur il suffit de recompiler. C’est à peu près le cas de 95% (et encore je suis large) des applis qu’on trouve dans une distro. Ca fait plusieurs années que je fais tourner du Debian full desktop sur des boards ARM, aucun problème particulier.





  • Peut-on créer des machines virtuelles x86 qui tournent sur ARM ?



    Oui, QEMU marche pas trop mal.



Le 30/04/2013 à 17h 13







Ricard a écrit :



<img data-src=" />



La nouvelle Debian Wheezy sort dans 1 semaine.<img data-src=" />



Avec un noyau 3.2<img data-src=" />







La branche stable seulement









fred42 a écrit :



Vivement le 3.14.16 !<img data-src=" />



<img data-src=" />









Ricard a écrit :



<img data-src=" />



La nouvelle Debian Wheezy sort dans 1 semaine.<img data-src=" />



Avec un noyau 3.2<img data-src=" />





Disons que chez Debian c’est trèèèès progressif <img data-src=" />



Debian Stable (Squeeze) : Linux 2.6

Debian Testing (Wheezy) : Linux 3.2

Debian Unstable (Sid) : Linux 3.2

Debian Experimental : Linux 3.8









fred42 a écrit :



Vivement le 3.14 !<img data-src=" />





Peut-être pour le 14 mars prochain ? <img data-src=" />









ff9098 a écrit :



La branche stable seulement





Ben Wheezy, ce sera la branche stable.<img data-src=" />



Le 30/04/2013 à 17h 38







Ricard a écrit :



Ben Wheezy, ce sera la branche stable.<img data-src=" />







Oui mais non mais je me comprends <img data-src=" />



Wouaw! je ne savais pas que le doigt d’honneur ait fonctionné, quel retour de #veste <img data-src=" />








2show7 a écrit :



Wouaw! je ne savais pas que le doigt d’honneur ait fonctionné, quel retour de #veste <img data-src=" />







Maintenant tu sais quoi faire pour que ton patron t’offre une augmentation. ;)



Il n’y a rien de méchant dans ma réponse <img data-src=" />, mais je me méfie des Para-doxe <img data-src=" />








Konrad a écrit :



Changements intéressants. Puisqu’on parle de pilotes, il me semblait que nVidia se décidait enfin à développer le support d’Optimus, mais j’imagine que ça sera pour une prochaine version…



D’ailleurs une question bête me taraude l’esprit : la version suivante sera-t-elle la 4.0, ou 3.10 ? Question hautement existentielle <img data-src=" />





Le support d’Optimus par Nvidia concerne les pilotes proprios de Nvidia si je ne me trompe pas. Donc ça ne sera pas présent dans le noyau linux. À moins que Nvidia change complètement de politique, mais ça m’étonnerait vraiment.



Le 01/05/2013 à 01h 05







arobase40 a écrit :



Pour ce qui est des pilotes graphiques Intel, il y a clairement du boulot à abattre, car c’est franchement le bordel et une véritable régression depuis la version 3.2.x !!! <img data-src=" />



C’est soit écran noir total, soit affichage brouillé, soit limitation au 1026x768 avec ma mobo GA-H77N-Wifi + Core i5… <img data-src=" />



Donc, faut jouer du xrandr pour avoir un affichage étendu, surtout au delà du 1280x800….



Et de ce que j’ai constaté, je suis loin d’être le seul dans la même situation…







J’ai aucun problème pour ma part









Konrad a écrit :



Changements intéressants. Puisqu’on parle de pilotes, il me semblait que nVidia se décidait enfin à développer le support d’Optimus, mais j’imagine que ça sera pour une prochaine version…



D’ailleurs une question bête me taraude l’esprit : la version suivante sera-t-elle la 4.0, ou 3.10 ? Question hautement existentielle <img data-src=" />











pamputt a écrit :



Le support d’Optimus par Nvidia concerne les pilotes proprios de Nvidia si je ne me trompe pas. Donc ça ne sera pas présent dans le noyau linux. À moins que Nvidia change complètement de politique, mais ça m’étonnerait vraiment.







Petit hors-sujet mais il semblerait qu’il ne faut pas remercier nVidia mais la communauté :

http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.htm…









jedifox a écrit :



Petit hors-sujet mais il semblerait qu’il ne faut pas remercier nVidia mais la communauté :

http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.htm…





Merci pour le lien. Le parallèle avec les pilotes WiFi et ARM montre à quel point la logique “tout-proprio” de nVidia est stupide et anti-productive…



Le 01/05/2013 à 12h 29

Bin l’actualité “négative” n’est pas sur linux mais sur gcc… qui depuis sa version 4.8, il ne peut plus être bootstrapé avec un petit compilateur C (C89) mais impose un compilateur c++ (voir runtime c++ complet). llvm a fait les mêmes mauvais choix, mais dés le départ.



<img data-src=" />



Pour ma part, c’est la goutte. Ça va être pénible de mettre gcc a la poubelle (car le fork est totalement déraisonnable), mais bon… va falloir le faire maintenant.


Le 01/05/2013 à 12h 54







sylware a écrit :



Bin l’actualité “négative” n’est pas sur linux mais sur gcc… qui depuis sa version 4.8, il ne peut plus être bootstrapé avec un petit compilateur C (C89) mais impose un compilateur c++ (voir runtime c++ complet). llvm a fait les mêmes mauvais choix, mais dés le départ.



<img data-src=" />



Pour ma part, c’est la goutte. Ça va être pénible de mettre gcc a la poubelle (car le fork est totalement déraisonnable), mais bon… va falloir le faire maintenant.







En quoi ça pose problème ?









RBoudin a écrit :



En quoi ça pose problème ?







Les vrais hommes programment en C.



Les langages-objets c’est pour les fillettes.









Jonathan Livingston a écrit :



Les vrais hommes programment en C.



Les langages-objets c’est pour les fillettes.





Les vrais hommes programment en assembleur sans OS. Le reste c’est pour les faiblards <img data-src=" />



Blague a part le fait que gcc soit en C++ ne pose pas de probleme surtout que le C++ utilise est au final assez light. Et ca vient de quelqu’un que les langages OO repugnent (sauf CLOS…).









ldesnogu a écrit :



Les vrais hommes programment en assembleur sans OS codent en établissant des connections avec des morceaux de fils et un fer à souder. Le reste c’est pour les faiblards <img data-src=" />



Blague a part le fait que gcc soit en C++ ne pose pas de probleme surtout que le C++ utilise est au final assez light. Et ca vient de quelqu’un que les langages OO repugnent (sauf CLOS…).







<img data-src=" />




Le 01/05/2013 à 14h 59







ldesnogu a écrit :



Les vrais hommes programment en assembleur sans OS. Le reste c’est pour les faiblards <img data-src=" />



Blague a part le fait que gcc soit en C++ ne pose pas de probleme surtout que le C++ utilise est au final assez light. Et ca vient de quelqu’un que les langages OO repugnent (sauf CLOS…).







Surtout que le fait de se restreindre au C posait de gros problèmes de maintenabilité.



Un article qui explique bien la décision http://lwn.net/Articles/542457/




Le 01/05/2013 à 16h 34







RBoudin a écrit :



En quoi ça pose problème ?







<img data-src=" />



Le 01/05/2013 à 19h 05







sylware a écrit :



<img data-src=" />







Justement, il n’y a aucun réel argument contre (si ce n’est que la majorité des contributeurs GCC actuel sont des codeurs C, mais ça c’est un faux problème).



Le 01/05/2013 à 23h 18







sylware a écrit :



Bin l’actualité “négative” n’est pas sur linux mais sur gcc… qui depuis sa version 4.8, il ne peut plus être bootstrapé avec un petit compilateur C (C89) mais impose un compilateur c++ (voir runtime c++ complet). llvm a fait les mêmes mauvais choix, mais dés le départ.







C’est sur qu’entre les dev gcc/llvm et toi, c’est toi qui as raison. Aller lance ton fork



Le 03/05/2013 à 10h 50







ff9098 a écrit :



C’est sur qu’entre les dev gcc/llvm et toi, c’est toi qui as raison. Aller lance ton fork







Il n’y a pas que llvm et gcc.



Le 03/05/2013 à 10h 52







RBoudin a écrit :



Justement, il n’y a aucun réel argument contre (si ce n’est que la majorité des contributeurs GCC actuel sont des codeurs C, mais ça c’est un faux problème).







google mieux.