Le noyau Linux 3.3 intègre directement plusieurs pilotes Android
Il devient possible de lancer des applications Android sur Linux
La version 3.3 du noyau Linux a été publiée. Elle contient comme d’habitude de multiples améliorations mais cette mouture se signale surtout par la réintégration de plusieurs modifications en provenance d’Android, donc de Google.
Linuxfr.org a publié la très longue liste des apports du noyau Linux 3.3. On trouve diverses nouveautés comme des améliorations sur le système de fichiers Btrfs, l’ajout du commutateur réseau virtuel Open vSwitch, le remplacement à chaud des disques RAID, un nouveau gestionnaire de surveillance des batteries ou encore le support de l’architecture C6X de Texas Instrument (embarqué).
La partie concernant Android remet sur le tapis la manière dont le code est intégré dans le noyau Linux. Il ne s’agit pas en effet de la première fois que du code était présenté pour intégration. Plusieurs pilotes Android avait en effet failli faire parti du noyau avant d’être rejetés fin 2009 à cause d’un manque de suivi de la part de Google.
Comme l’explique Ars Technica notamment, les développeurs utilisent la branche « staging » du noyau Linux pour présenter du code en vue d’une intégration prochaine. Il s’agit en quelque sorte d’une antichambre dans laquelle les éléments attendent leur maturation car ils ne sont pas jugés assez bons pour la production. En 2009, les pilotes Android faisaient partie de cette branche mais le mainteneur principal, Greg Kroah-Hartman, avait fini par indiquer qu’ils semblaient « abandonnés ».
En novembre 2011, Kroah-Hartman réintègre les pilotes Android dans la branche staging, avec succès cette fois comme en témoigne cette version 3.3. Plusieurs composants sont donc désormais présents :
Comme d’habitude, le nouveau noyau sera déployé progressivement sur les distributions ou dans leurs versions ultérieures.
Linuxfr.org a publié la très longue liste des apports du noyau Linux 3.3. On trouve diverses nouveautés comme des améliorations sur le système de fichiers Btrfs, l’ajout du commutateur réseau virtuel Open vSwitch, le remplacement à chaud des disques RAID, un nouveau gestionnaire de surveillance des batteries ou encore le support de l’architecture C6X de Texas Instrument (embarqué).
La partie concernant Android remet sur le tapis la manière dont le code est intégré dans le noyau Linux. Il ne s’agit pas en effet de la première fois que du code était présenté pour intégration. Plusieurs pilotes Android avait en effet failli faire parti du noyau avant d’être rejetés fin 2009 à cause d’un manque de suivi de la part de Google.
Comme l’explique Ars Technica notamment, les développeurs utilisent la branche « staging » du noyau Linux pour présenter du code en vue d’une intégration prochaine. Il s’agit en quelque sorte d’une antichambre dans laquelle les éléments attendent leur maturation car ils ne sont pas jugés assez bons pour la production. En 2009, les pilotes Android faisaient partie de cette branche mais le mainteneur principal, Greg Kroah-Hartman, avait fini par indiquer qu’ils semblaient « abandonnés ».
En novembre 2011, Kroah-Hartman réintègre les pilotes Android dans la branche staging, avec succès cette fois comme en témoigne cette version 3.3. Plusieurs composants sont donc désormais présents :
- Ashmem (Android shared memory), un mécanisme de partage de la mémoire vive
- Binder, qui permet la communication entre les processus
- Logger, une infrastructure de log
- Le mécanisme « low memory killer » qui permet de faire le ménage dans les processus quand la mémoire vient à manquer
Comme d’habitude, le nouveau noyau sera déployé progressivement sur les distributions ou dans leurs versions ultérieures.
Source :
Kernel Newbies
Vincent Hermann
Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.
Le 20 mars 2012 à 11:13
(18 424
lectures)
Il y a 69 commentaires
OMG, ce mec sait faire une présentation non ennuyeuse
Sauf quand tu as une vieille bécane et que tu essaie de charger le système en RAM.
Ca dépend de comment est monté la config du noyaux... si tous les pilotes et options sont en dur, effectivement c'est pas top
Mais la plus part du temps la majorité des éléments non utile pour le boot sont en module et ne se chargent que si besoin. (Par exemple c'est toujours sympa de mettre le system de fichier / en module sans initram pour le charger au boot
)
Ca dépend de comment est monté la config du noyaux... si tous les pilotes et options sont en dur, effectivement c'est pas top
Mais la plus part du temps la majorité des éléments non utile pour le boot sont en module et ne se chargent que si besoin. (Par exemple c'est toujours sympa de mettre le system de fichier / en module sans initram pour le charger au boot
)De toute façon, mon driver wifi n'est pas intégré par défaut, et il y a plein de trucs intégrés qui ne me servent pas. Je préfère le recompiler (éventuellement) et l'optimiser au maximum. J'ai un SSD de 8Gio, et 512 Mo de RAM sur cette machine, et avec l'option "linux copy2ram" au noyau, je charge le système en RAM.
Là tu peux comprendre l'avantage.
Pas vraiment, ext4 est un peu plus rapide que Btrfs (pour l'instant) mais ce dernier favorise certaines opérations de compression particulièrement utiles pour android.
Référence : Benchmark Phoronix
Le dernier article que j'ai lu sur le sujet m'a un peu calmé sur les données à stocker sur ce fs.
De toute façon, mon driver wifi n'est pas intégré par défaut, et il y a plein de trucs intégrés qui ne me servent pas. Je préfère le recompiler (éventuellement) et l'optimiser au maximum. J'ai un SSD de 8Gio, et 512 Mo de RAM sur cette machine, et avec l'option "linux copy2ram" au noyau, je charge le système en RAM.
Là tu peux comprendre l'avantage.

Effectivement.
De toutes façons ca ne prend pas non plus des semaines pour configurer un noyaux :)
Sur ma machine perso je viens de migrer mes ext3 en ext4 (même le / , sans faire de sauvegarde :memepaspeur: ) et j'ai une partoche en xfs (je me rappel plus pourquoi ce choix XD)
Pas peur en effet
Pour Xfs, je devine : pour tout ce qui est X et Fesses ?
Edit:
Note pour plus tard : EXT4 > EXT3
Edité par JCDentonMale le mardi 20 mars 2012 à 12:49
Effectivement.
De toutes façons ca ne prend pas non plus des semaines pour configurer un noyaux :)
Surtout que c'est pour un petit serveur perso, donc bon...
Je serai toujours épaté par la rapidité de progression de ce projet malgré un code de plus en plus difficile à maintenir
Ça veut dire Better FS.Ah mince je pensais que c'était le système de fichier en beurre...
Butter FS

Edité par ZeblodS le mardi 20 mars 2012 à 13:16
Ca dépend de comment est monté la config du noyaux... si tous les pilotes et options sont en dur, effectivement c'est pas top
Mais la plus part du temps la majorité des éléments non utile pour le boot sont en module et ne se chargent que si besoin. (Par exemple c'est toujours sympa de mettre le system de fichier / en module sans initram pour le charger au boot
)Tu parles d'avoir tous les modules indispensable au boot en dur dans le noyau ou d'avoir l'équivalent du contenu de initram dans un module ? (j'ai comme un doute sur la viabilité de la seconde solution mais on ne sait jamais).
Il n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.













