La couche d’abstraction Hexo

La couche d’abstraction du matériel fournit les services essentiels à l’hétérogénéité. Ces services permettent de garantir l’uniformité du comportement des différents types de processeurs vis-à-vis de la plateforme. Ces mécanismes ont déjà été présentés dans la section 3.4.

L’implémentation de cette couche d’abstraction a été réalisée de manière à minimiser et même sup-primer le coût de l’abstraction. En effet, la modularité du logiciel n’exclut pas la définition de nom-breuses fonctions static inline dans les fichiers entêtes. Il s’agit ici de modularité statique, et

4.2. LES MODULES ESSENTIELS 75 non de modularité dynamique qu’on traiterait par pointeurs sur fonctions : tout se trouve donc réduit à la compilation. Même si le code source est localisé et regroupé par type de processeur et par type de plateforme, la configuration sélectionne les fichiers à inclure et le compilateur se charge d’inliner le code.

Hexo reste donc une couche très fine qui, une fois traitée par le compilateur, est alors complètement intégrée dans les couches plus hautes du noyau. Les services présentés précédemment sont fournis au travers de divers entêtes :

– hexo/init.h : démarrage et initialisation du système

– hexo/cpu.h : invalidation du cache et accès aux registres spécifiques du processeur – hexo/atomic.h : services d’accès atomiques à la mémoire

– hexo/ordering.h : sérialisation des accès à la mémoire par le compilateur et le processeur – hexo/lock.h : service de verrous de type spinlock

– hexo/endian.h : services d’accès mémoire non-alignés et d’endianness non native – hexo/iospace.h : services d’accès à l’espace d’adressage des périphériques – hexo/local.h : variables contextuelles.

– hexo/mmu.h : support de la mémoire virtuelle. – hexo/types.h : définitions de types entiers portables – hexo/context.h : gestion des contextes d’exécution

– hexo/interrupt.h : gestion des interruptions, exceptions et appels système – hexo/ipi.h : gestion des interruptions inter-processeurs

Outre la modularité et l’attention particulière apportée lors de la réalisation, afin que ces différents services se comportent de la même manière avec des processeurs différents, l’implémentation et l’API de la plupart de ces services restent classiques. Le support de l’hétérogénéité est assuré davan-tage par le choix de l’API et sa généricité que par son implémentation, ainsi que nous l’avons exposé dans les solutions. Seuls quelques services, telle la gestion des contextes d’exécution, méritent une présentation plus détaillée.

Gestion des contextes d’exécution

Hexo propose une API générique pour sauvegarder et restaurer un contexte d’exécution indépen-damment du type de processeur. La couche d’abstraction du matériel offre uniquement le service de sauvegarde, c’est-à-dire le stockage de l’état du processeur dans un contexte dédié en mémoire. Ce contexte contient les valeurs des registres du processeur et reste spécifique au type de processeur. La figure 4.8 donne un exemple d’utilisation de l’API. Dans cet exemple deux contextes d’exécution peuvent être sauvegardés dans les variables ctx_a et ctx_b et utilisent les piles déclarées par stack_aet stack_b. Chaque contexte invoque sa sauvegarde et la restauration de l’autre contexte dans une boucle sans fin.

Il est important de noter que dans un système hétérogène, un contexte sauvegardé par un processeur, ne peut être restauré que sur un processeur du même type. Cette limitation est en accord avec le type d’hétérogénéité visée et assure la correspondance du code, avec une granularité au niveau fonctions, entre les différents processeurs. La sauvegarde du contexte d’exécution pouvant s’effectuer à

n’im-76 CHAPITRE 4. RÉALISATION DU NOYAU

static CONTEXT_ENTRY(context_entry) {

struct context_s *other = param; while (1)

context_switch_to(other); }

/* execution contexts and associated stacks */

struct context_s ctx_a, ctx_b;

uint8_t stack_a[512], stack_b[512]; void main()

{

/* initialize context A and pass context B as entry parameter */

context_init(&ctx_a, stack_a, stack_a + 512, context_entry, &ctx_b);

/* initialize context B and pass context A as entry parameter */

context_init(&ctx_b, stack_b, stack_b + 512, context_entry, &ctx_a);

/* discard current context and restore context A */

context_jump_to(&ctx_a); }

FIGURE4.8 – Exemple de permutations infinies entre deux contextes A et B

porte quel instant de l’exécution du contexte dans un système multitâche préemptif, l’interruption d’un contexte à l’intérieur d’une fonction ne permet pas de la restaurer sur un autre processeur. Un changement de contexte sur appel de fonction n’est pas viable pour autant : un autre obstacle est l’utilisation de conventions d’appels (ABI) différentes entre les processeurs. Ceci implique que le format de la pile d’exécution d’un contexte diffère selon le processeur sur lequel il s’exécute. Il n’est donc pas envisageable de réaliser la migration d’un contexte entre deux types de processeurs sans définir une ABI spécifique commune, car ceci impliquerait de réécrire une partie des outils de compilation.

Cette contrainte de migration de contexte sur un même type de processeur n’est pas une limitation forte puisque l’hétérogénéité est généralement mise à profit pour exploiter les atouts des différents processeurs et leur faire exécuter des tâches spécifiques.

Plateformes et processeurs supportés

Rappelons qu’Hexo distingue le code spécifique à la plateforme du code spécifique au processeur. Les plateformes supportées sont les suivantes :

– simple : Architecture monoprocesseur simple correspondant à des plateformes à base de micro-contrôleurs.

– ibmpc : Support de l’architecture des serveurs et stations de travail multiprocesseurs classiques de type PC.

– soclib : Support des plateformes SoCLib multiprocesseurs.

4.2. LES MODULES ESSENTIELS 77 Les différents types de processeurs supportés par Hexo à ce jour sont les suivants :

– Les processeurs x86 32 bits et x86_64. – Les processeurs PowerPC

– Les processeurs Mips 32bits big endian et little endian. – Les processeurs ARM

– Les microcontrôleurs Atmel AVR.

L’architecture utilisée pour les expérimentations sur des plateformes multiprocesseurs hétérogènes est l’architecture SoCLib.

Le support de l’architecture ibmpc a permis d’assurer un degré important de généricité du code tant cette architecture diffère d’une architecture moderne employant des processeurs RISC. Ceci a également permis de tester le noyau sur une plateforme multiprocesseur éprouvée et totalement fiable.

L’architecture emu est particulière puisqu’elle permet l’exécution du noyau MutekH dans un proces-sus utilisateur au-desproces-sus du noyau Linux ou Darwin. Son principe est similaire à celui de User-mode Linux[13]. Dans ce mode, le binaire du noyau est une application indépendante, liée à aucune bi-bliothèque du système d’exploitation hôte. Seuls quelques appels système directs sont effectués vers le noyau : pour allouer un unique bloc mémoire servant de RAM, ou encore pour accéder aux en-trées/sorties. emu supporte les architectures multiprocesseurs en créant plusieurs processus et en employant les services de mémoire partagée du noyau hôte. Comme sur les architectures soclib et ibmpc, il est possible d’obtenir de la vraie concurrence si la machine hôte est munie de plusieurs processeurs. Cette architecture a permis de tester tous les aspects algorithmiques du noyau sans re-courir à du matériel spécifique, avec une vitesse d’exécution native, tout en facilitant l’utilisation d’outils de débogage.