Kernel Corner : Noyau 3.1 (suite)

Magazine
Marque
GNU/Linux Magazine
Numéro
144
Mois de parution
décembre 2011


Résumé

Suite et fin de notre synthèse des nouveautés de Linux 3.1, noyau à la genèse mouvementée. Si l'attaque de kernel.org a causé l'indisponibilité de l'ensemble de l'infrastructure de développement habituelle, elle aura finalement seulement ralenti le travail et n'aura en rien compromis le code, en partie grâce au gestionnaire de versions Git créé par Linus Torvalds. Par sa nature décentralisée, il ne repose pas sur un point unique de stockage des données. Finalement, cette attaque aura eu comme avantage de déclencher une remise à plat de la sécurité de kernel.org, beaucoup plus stricte désormais.


1. Virtualisation

1.1 Xen

1.1.1 Optimisation de l'utilisation de la mémoire par Xen : Self-ballooning et Frontswap-selfshrinking

1.1.1.1 Vue d'ensemble

Dans un environnement virtualisé tel que Xen, la mémoire vive est souvent une ressource précieuse que l'on souhaite être utilisée de la façon la plus efficiente par les (potentiellement) nombreuses machines virtuelles s'exécutant. On entend par cela qu'une machine virtuelle ne fasse pas de gaspillage de mémoire, et ainsi qu'elle n'en utilise que peu lorsque sa charge est faible et qu'elle en obtienne autant que nécessaire en forte charge.

Cette version du noyau voit l'intégration de deux nouvelles techniques pour optimiser dynamiquement cette utilisation que fait Xen de la mémoire pour gérer ses machines virtuelles. Ces techniques s'appuient sur la mémoire transcendante (cf. Kernel Corner 140) et viennent enrichir les deux frontends existants de mémoire transcendante (cf. Kernel Corner 142) : cleancache...

Cet article est réservé aux abonnés. Il vous reste 97% à découvrir.
S'abonner à Connect
  • Accédez à tous les contenus de Connect en illimité
  • Découvrez chaque semaine un nouvel article premium
  • Consultez les nouveaux articles en avant-première
Je m'abonne


Article rédigé par

Par le(s) même(s) auteur(s)

Fuddly : introduction de l’outil et développement d’un protocole

Magazine
Marque
MISC
Numéro
103
Mois de parution
mai 2019
Spécialité(s)
Résumé

Cet article présente Fuddly, un framework de fuzzing et de manipulation de données, écrit en python sous GPLv3, qui fournit de nombreuses briques que l’on retrouve dans d’autres framework de fuzzing, mais qui se différencie par la flexibilité de représentation des données et la diversité des altérations qu’il rend possible.

L'Infrastructure Linux Gadget USB

Magazine
Marque
Open Silicium
Numéro
14
Mois de parution
mars 2015
Spécialité(s)
Résumé

L'infrastructure Gadget USB du noyau Linux facilite la création de périphériques USB, en proposant un cadre et un certain nombre de primitives qui permettent d'une part d'abstraire les contrôleurs matériels de périphériques USB, et d'autre part d'en utiliser les ressources et fonctionnalités afin de créer n'importe quelle fonction USB désirée : qu'elle réponde aux standards (tels que « Mass Storage », « CDC Eth »…), qu'elle soit l'incarnation de vos besoins particuliers, ou bien encore qu'elle soit une combinaison des deux.

Les derniers articles Premiums

Les derniers articles Premium

Du graphisme dans un terminal ? Oui, avec sixel

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

On le voit de plus en plus, les outils en ligne de commandes s'étoffent peu à peu d'éléments graphiques sous la forme d'émojis UTF8. Plus qu'une simple décoration, cette pointe de « graphisme » dans un monde de texte apporte réellement un plus en termes d'expérience utilisateur et véhicule, de façon condensée, des informations utiles. Pour autant, cette façon de sortir du cadre purement textuel d'un terminal n'est en rien une nouveauté. Pour preuve, fin des années 80 DEC introduisait le VT340 supportant des graphismes en couleurs, et cette compatibilité existe toujours...

Game & Watch : utilisons judicieusement la mémoire

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous