Noyau Linux - Séance 7

5- Noyau Linux et Développement de Pilotes
Noyau Linux et Développement de Pilotes

Cours du Système Embarqué et Temps Réel
Prof. Nabil KANNOUF
UAE – ENSAH
12 novembre 2021
Plan
1 Noyau Linux
Origine de Linux
Philosophie Unix
Architecture de noyau
Mécanismes du noyau Linux
Gestion des entrées/sorties
Linux et systèmes d’exploitation temps réel
2 Développement de Pilotes
Modules de noyau Linux
Développer pour le noyau
Primitives de synchronisation du noyau
Gestion des interruptions
Dispositifs de caractères
Implémentation du dispositif scull
5.1- Noyau Linux
5.1- Noyau Linux

5.1- Noyau Linux
5.1.1- Origine de Linux

5.1- Noyau Linux
Qu’est-ce que Linux ?
Vous connaissez tous bien Linux !

� Vous l’utilisez dans plusieurs cours
� Dispositifs électroniques courants basés sur Linux
� Téléphones et autres dispositifs Android
� Variété de dispositfs embarqués
� Services dans le nuage
5.1- Noyau Linux
Qu’est-ce que Linux ?
Vous connaissez tous bien Linux !

� Vous l’utilisez dans plusieurs cours
� Dispositifs électroniques courants basés sur Linux
� Téléphones et autres dispositifs Android
� Variété de dispositfs embarqués
� Services dans le nuage
Mais connaissez-vous vraiment Linux ?
� Les origines et la philosophie derrière Linux
� Organisation générale du noyau
� Approches relativement aux différents éléments d’un noyau
5.1- Noyau Linux
Origines de Linux
Années 1970 : Développement et adoption d’Unix

5.1- Noyau Linux
Origines de Linux

Années 1980
� Conflit légal entre AT&T et BSD, ce qui ralentit l’adoption de BSD
� Projet GNU (GNU’s Not Unix), un clone libre d’Unix
� Développement d’une suite de programmes, librairies et outils de développements
� Noyau Hurd : projet ambitieux qui n’a jamais vraiment décollé
5.1- Noyau Linux
Origines de Linux

Années 1980
Fin années 1980 : Noyau MINIX d’Andrew Tanenbaum
� Implémentation d’un noyau Unix à fins académiques
� Présenté dans le détail dans le livre Operating Systems : Design and Implementation
5.1- Noyau Linux
Origines de Linux

Années 1980
Fin années 1980 : Noyau MINIX d’Andrew Tanenbaum
� Implémentation d’un noyau Unix à fins académiques
� Présenté dans le détail dans le livre Operating Systems : Design and Implementation
1991 : lancement du noyau Linux
� Linus Torvalds, étudiant à l’Université d’Helsinki, veut exploiter architecture 32 bits
et MMU de son nouveau PC 386
� Inspiré de MINIX, mais code MINIX rapidement éliminé
� Utilise l’environnement GNU pour complémenter le noyau
5.1- Noyau Linux
Just for fun

Hello everybody out there using minix -
I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.
This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike
in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons)
among other things).
I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I’ll get something
practical within a few months, and I’d like to know what features most people would want. Any suggestions are
welcome, but I won’t promise I’ll implement them :-).
Linus (torvaldskruuna.helsinki).
PS. Yes - it’s free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching
etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(.
– Linus Torvalds
5.1- Noyau Linux
Logiciel libre et développement collaboratif
Linux est un logiciel libre et développé selon un modèle collaboratif

� Le code est disponible gratuitement et libre de droit
� Tout le monde peut modifier le code, mais les modifications doivent aussi être ouvertes,
si distribuées
� Développements de la version officielle de Linux toujours gérée par Linus Torvalds
� Linus agis comme « dictateur bienveillant »
� Communauté de hackers supportant Linus et discutant ouvertement des changements
proposés
� Basé sur la méritocratie, la barre est haute pour entrer dans cette communauté
5.1- Noyau Linux

si distribuées
proposés
Autres logiciels de la suite GNU sont développés selon modèle similaire
� Communautés différentes que celle du noyau, niveau d’activités variable selon projet
� Objectif du projet GNU atteint : offrir un clone d’Unix, mais ouvert et libre
5.1- Noyau Linux

si distribuées
proposés
Autres logiciels de la suite GNU sont développés selon modèle similaire
� Communautés différentes que celle du noyau, niveau d’activités variable selon projet
� Objectif du projet GNU atteint : offrir un clone d’Unix, mais ouvert et libre
Linux et le projet GNU se sont développés dans la philosophie Unix
5.1- Noyau Linux
5.1.2- Philosophie Unix

5.1- Noyau Linux
Philosophie Unix
Mais qu’est-ce que la philosophie Unix ?
� Réflexion de Ken Thompson (co-créateur d’Unix) : concevoir un SE petit, mais
capable, avec une interface de service bien conçu et clair
� Unix est bottom-up et non top-down ; c’est une philosophie pragmatique et basée sur
l’expérience
5.1- Noyau Linux
Philosophie Unix
Mais qu’est-ce que la philosophie Unix ?
� Réflexion de Ken Thompson (co-créateur d’Unix) : concevoir un SE petit, mais
capable, avec une interface de service bien conçu et clair
� Unix est bottom-up et non top-down ; c’est une philosophie pragmatique et basée sur
l’expérience
Selon Doug McIlroy (1978) :
1 Make each program do one thing well. To do a new job, build afresh rather than
complicate old programs by adding new features.
2 Expect the output of every program to become the input to another, as yet unknown,
program. Don’t clutter output with extraneous information. Avoid stringently columnar
or binary input formats. Don’t insist on interactive input.
3 Design and build software, even operating systems, to be tried early, ideally within
weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
4 Use tools in preference to unskilled help to lighten a programming task, even if you
have to detour to build the tools and expect to throw some of them out after you’ve
finished using them.
5.1- Noyau Linux
Règles de la philosophie Unix
Philosophie Unix formalisée plus en détail par Eric S. Raymond

� 17 règles énoncées pour capturer les éléments importants de la philosophie Unix
� Utiles pour bien comprendre comment Unix et plusieurs systèmes d’exploitation fonc-
tionnent
� Philosophie également très pertinente pour développer une approche éprouvée pour
développement logiciel et de systèmes ordinés
� Présenté dans le livre The Art of UNIX Programming (2003)
� Version en ligne disponible gratuitement à http ://www.catb.org/esr/writings/taoup/
5.1- Noyau Linux
Règles de modularité et de clarté
1 Règle de modularité : écrire des parties simples connectées par des interfaces claires
� Déboggage domine temps de développement

� Réussir à concevoir système fonctionnel plus une question de ne pas s’empêtrer dans
son propre code que d’avoir un design brillant
� Seule façon de faire logiciel complexe est de minimiser complexité globale
� Faire des parties simples et connectées par des interfaces bien définies
� Ainsi, plupart des problèmes sont locaux, donc modifier une partie ne brise pas le tout
5.1- Noyau Linux
Règles de modularité et de clarté
1 Règle de modularité : écrire des parties simples connectées par des interfaces claires
� Déboggage domine temps de développement

� Réussir à concevoir système fonctionnel plus une question de ne pas s’empêtrer dans
son propre code que d’avoir un design brillant
� Seule façon de faire logiciel complexe est de minimiser complexité globale
� Faire des parties simples et connectées par des interfaces bien définies
� Ainsi, plupart des problèmes sont locaux, donc modifier une partie ne brise pas le tout
2 Règle de clarté : la clarté est préférable à l’ingéniosité
� Maintenance est importante et coûteuse ; code lisible par humain plus important que
code ingénieux
� Penser à la personne qui devra modifier votre code, incluant vous dans le futur
� Code gracieux et clair est moins propice à défaillances
5.1- Noyau Linux
Règles de composition et de séparation

3 Règle de composition : concevoir des programmes qui seront connectés à d’autres
programmes
� Difficile d’éviter monolithes complexes si programmes ne peuvent pas se parler
� Tradition Unix encourage programmes pouvant lire et écrire au format simple,
textuel, orienté flot et indépendant de l’architecture
� Programmes souvent écrits comme filtres simples avec flot textuel en entrée, traitement
des données et sortie du résultat comme flot textuel
� Pour favoriser compositionnalité, faire des programmes indépendants
� Ne pas se soucier des programmes connectés, remplacement d’une implémentation pas
une nouvelle ne devrait pas altérer fonctionnement global
5.1- Noyau Linux
Règles de composition et de séparation

3 Règle de composition : concevoir des programmes qui seront connectés à d’autres
programmes
� Difficile d’éviter monolithes complexes si programmes ne peuvent pas se parler
� Tradition Unix encourage programmes pouvant lire et écrire au format simple,
textuel, orienté flot et indépendant de l’architecture
� Programmes souvent écrits comme filtres simples avec flot textuel en entrée, traitement
des données et sortie du résultat comme flot textuel
� Pour favoriser compositionnalité, faire des programmes indépendants
� Ne pas se soucier des programmes connectés, remplacement d’une implémentation pas
une nouvelle ne devrait pas altérer fonctionnement global
4 Règle de séparation : séparer politique des mécanismes ; séparer interfaces des
engins
� Politiques changent plus vites que mécanismes
� Allure d’une interface graphique (politiques) vs affichage d’une image (mécanismes)
� Programmer dans un langage interprété (politiques) vs routines de bases en C (méca-
nismes)
5.1- Noyau Linux
Règles de simplicité et de parcimonie
5 Règle de simplicité : concevoir pour la simplicité ajouter de la complexité seule-

ment lorsque c’est nécessaire
� Pressions diverses pour rendre programme plus complexe : machisme technique, fonc-
tionnalités supplémentaires inutiles (feature checklist)
� Résister à ces pièges en favorisant solutions simples (small is beautiful)
5.1- Noyau Linux
Règles de simplicité et de parcimonie
5 Règle de simplicité : concevoir pour la simplicité ajouter de la complexité seule-

ment lorsque c’est nécessaire
� Pressions diverses pour rendre programme plus complexe : machisme technique, fonc-
tionnalités supplémentaires inutiles (feature checklist)
� Résister à ces pièges en favorisant solutions simples (small is beautiful)
6 Règle de parcimonie : écrire de gros programmes seulement lorsqu’il est clairement
démontré que rien d’autre ne fonctionne
� Permettre des gros programmes (en nombre de lignes de code) rends maintenance
plus difficile
� Résistance à l’idée de jeter résultat d’un travail consiéerable
� Gros programmes amènent investissement supplémentaire dans approches ayant échouées
ou sous-optimales
5.1- Noyau Linux
Règles de transparence et de robustesse
7 Règle de transparence : concevoir pour la visibilité afin de rendre inspection et

débogage plus aisés
� Débogage prend trois quarts du temps de développement
� Concevoir pour transparence : au premier regard on peut comprendre ce qui est fait
� Concevoir pour découvrabilité : suivi et affichage de l’état interne permettant de
valider bon fonctionnement
5.1- Noyau Linux
Règles de transparence et de robustesse
7 Règle de transparence : concevoir pour la visibilité afin de rendre inspection et

débogage plus aisés
� Débogage prend trois quarts du temps de développement
� Concevoir pour transparence : au premier regard on peut comprendre ce qui est fait
� Concevoir pour découvrabilité : suivi et affichage de l’état interne permettant de
valider bon fonctionnement
8 Règle de robustesse : la robustesse est l’enfant de la transparence et de la simplicité
� Logiciel est robuste lorsqu’il performe bien autant dans conditions normales
qu’inattendues
� Plupart des logiciels fragiles, parce que trop compliqués pour être compris par
humains
� Si on ne peut pas comprendre, comment être certain de la rectitude
� Éviter cas particuliers, car bogues proviennent souvent de là
5.1- Noyau Linux
Règles de la représentation et de la moindre surprise
9 Règle de la représentation : placer la connaissance dans les données afin de rendre

logique du programme stupide et robuste
� Beaucoup plus facile de raisonner sur structures de données complexes que sur procé-
dure complexe
� Données sont plus faciles à tracer que programmes
� Déplacer complexité des programmes vers les données autant que possible
5.1- Noyau Linux
Règles de la représentation et de la moindre surprise
9 Règle de la représentation : placer la connaissance dans les données afin de rendre

logique du programme stupide et robuste
� Beaucoup plus facile de raisonner sur structures de données complexes que sur procé-
dure complexe
� Données sont plus faciles à tracer que programmes
� Déplacer complexité des programmes vers les données autant que possible
10 Règle de la moindre surprise : dans la conception d’interface, toujours faire la
chose la moins surprenante
� Programmes les plus faciles à utiliser sont ceux utilisant la connaissance préexistante
� Éviter des exercices d’ingéniosité et la nouveauté gratuite
� Opération + signifie toujours une addition dans un programme de calcul
� Faire attention à l’audience cible et aux traditions
5.1- Noyau Linux
Règles du silence et de la réparation
11 Règle du silence : lorsqu’un programme n’a rien à dire, il ne doit dire rien
� Le silence est d’or : éviter d’attirer inutilement attention des utilisateurs
� Information importante doit être visible, on s’y limite donc
5.1- Noyau Linux
Règles du silence et de la réparation
11 Règle du silence : lorsqu’un programme n’a rien à dire, il ne doit dire rien
� Le silence est d’or : éviter d’attirer inutilement attention des utilisateurs
� Information importante doit être visible, on s’y limite donc
12 Règle de la réparation : réparer si possible, mais si l’on doit échouer le faire aussi
bruyamment et hâtivement que possible
� Adaption aux situations inattendues est souhaitable
� Mais pire sorte de bogues est lorsque réparation échoue et problème créé corruption
apparaissant à rebours
� Donc, permettre logiciel de gérer entrées incorrectes autant que possible, échouer
bruyamment pour rendre diagnostic plus aisé
� Be liberal in what you accept, and conservative in what you send
� Être tolérant sur le format de ce qui est accepté
� Utiliser format fixe et standardisé pour les sorties
� Faire attention à l’audience cible et aux traditions
5.1- Noyau Linux
Règles de l’économie et de la génération
13 Règle de l’économie : temps des programmeurs est coûteux, y préférer temps des
machines
� Utiliser des langages de haut niveau autant que possible
5.1- Noyau Linux
Règles de l’économie et de la génération
13 Règle de l’économie : temps des programmeurs est coûteux, y préférer temps des
machines
� Utiliser des langages de haut niveau autant que possible
14 Règle de la génération : éviter de bidouiller à la main ; écrire des programmes qui
écrivent des programmes autant que possible
� Humains inaptes à gérer détails, programmes peuvent faire meilleur travail pour tâche
répétitive et/ou complexe
� Code généré souvent (à tous niveaux) plus fiable et supérieur à celui fait par humain
5.1- Noyau Linux
Règles d’optimisation, de diversité et d’extensibilité
15 Règle d’optimisation : prototyper avant de polir ; faire le travail avant de l’optimiser
� Automatiser tâches complexes

� Premature optimization is the root of all evil
� 90% et fonctionnel est mieux que 100% et non-fonctionnel
5.1- Noyau Linux

16 Règle de diversité : rejeter toutes affirmations comme quoi il n’y a qu’une seule
façon de faire
� Concevoir des logiciels rigides et fermés qui ne peuvent pas échanger avec d’autres
programmes ou agents est une forme malsaine d’arrogance
5.1- Noyau Linux

16 Règle de diversité : rejeter toutes affirmations comme quoi il n’y a qu’une seule
façon de faire
� Concevoir des logiciels rigides et fermés qui ne peuvent pas échanger avec d’autres
programmes ou agents est une forme malsaine d’arrogance
17 Règle d’extensibilité : concevoir pour le futur, comme c’est plus tôt que vous
pensez
� Utiliser des formats extensibles en permettant changements futurs
� Favoriser formats auto descriptifs
5.1- Noyau Linux
Philosphie Unix en bref
Tiré de Eric S. Raymond. The art of Unix programming. 2003, CC BY-ND 1.0 http ://www.catb.org/esr/writings/taoup/html/index.html.
5.1- Noyau Linux
5.1.3- Architecture de noyau

5.1- Noyau Linux
Linux est un noyau monolithique
� Noyau est un seul gros programme s’exécutant en mode privilégié
� Architecture des noyaux Unix traditionnels
� Un seul processus avec espace mémoire partagé
� Communications entre composantes effectuées par appel de fonction
5.1- Noyau Linux
Linux est un noyau monolithique
� Noyau est un seul gros programme s’exécutant en mode privilégié
� Architecture des noyaux Unix traditionnels
� Un seul processus avec espace mémoire partagé
� Communications entre composantes effectuées par appel de fonction
Micro-noyau
� Fonctionnalités du noyau séparées en processus distincts (serveurs), s’exécutant en
mode usager
� Seules fonctionnalités absolument essentielles s’exécutent en mode privilégié
� Communications par passage de messages
� Espace mémoire distinct pour chaque serveur
� Si un serveur échoue (ex. pilote), noyau reste opérationnel
� Surcoûts non négligeables (passage de messages et changement de mode d’exécution)
� Serveurs de SE à micro-noyau modernes (ex. Windows NT, Mach) s’exécutent en mode

privilégié
5.1- Noyau Linux
Noyau monolithique vs micro-noyau

5.1- Noyau Linux
Par Wooptoo [domaine public], via Wikimedia Commons, https ://commons.wikimedia.org/wiki/File :OS-structure.svg.
5.1- Noyau Linux
Caractéristiques du noyau
Caractéristiques de Linux
� Support pour chargement dynamique de modules
� Même si monolithique, code du noyau peut être chargé et déchargé à la demande
5.1- Noyau Linux
� Support pour exécution sur architecture multiprocesseur
� Non supporté sur implémentations traditionnelles d’Unix
5.1- Noyau Linux
� Noyau préemptif
� Tâches dans le noyau peuvent être préemptées
5.1- Noyau Linux
� Pas de différence entre processus et threads
� Distinction faite seulement par la configuration du partage de mémoire
5.1- Noyau Linux
� Modèle orienté objet de périphériques et de dispositifs
� Connections à chaud et système de fichiers dans l’espace utilisateur
5.1- Noyau Linux
� Modèle orienté objet de périphériques et de dispositifs
� Connections à chaud et système de fichiers dans l’espace utilisateur
� Ignore certaines fonctionnalités Unix considérées comme mal conçues
� Ex. pas de support pour STREAMS, architecture de communications entre noyau et
E/S
5.1- Noyau Linux
5.1.4- Mécanismes du noyau Linux

5.1- Noyau Linux
Modèle de threading
Trois types de tâches dans Linux
� Processus
� Espace mémoire distinct et exécution en mode usager
� Threads
� Espace mémoire partagé par tous les threads d’un processus
� Kthreads (threads du noyau)
� Pas d’espace mémoire propre, accès à l’espace mémoire du noyau
� Exécution en mode privilégié
5.1- Noyau Linux
� Processus
� Threads
Modèle de threading assez unique
� Avec d’autres SE (ex. Windows, Solaris), threads généralement une forme légère de processus (light-
weight process)
� Temps de création de processus/threads sous Linux se compare favorablement aux autres SE
5.1- Noyau Linux
� Processus
� Threads
Modèle de threading assez unique
� Avec d’autres SE (ex. Windows, Solaris), threads généralement une forme légère de processus (light-
weight process)
� Temps de création de processus/threads sous Linux se compare favorablement aux autres SE
Kthreads permettent préemption dans le noyau
� Code du noyau est réentrant
� Kthreads peuvent être préemptés tant qu’ils ne détiennent pas un lock
� Fonction schedule() peut être appelée par un kthread pour préemption explicite
5.1- Noyau Linux
Ordonnancement
Ordonnancement dans Linux
� Priorité par processus
� Nice entre -20 (haute priorité) et 19 (basse priorité) pour processus réguliers
� Facteur ≈ 3× pour différence de nice de 5
� Priorité temps réel entre 0 et 99 (nice de 0 correspond à priorité de 120)
� Completely Fair Scheduler (CFS) : quantum variable
� Quantum variable pour chaque exécution de processus
� Juste part calculée selon priorité (nice) du processus
� Valeur du quantum dépend des ressources consommées jusqu’à présent par le processus
relativement à sa juste part
� Processus avec part consommée plus faible sont prioritaires
5.1- Noyau Linux
Ordonnancement
Ordonnancement dans Linux
� Priorité par processus
� Nice entre -20 (haute priorité) et 19 (basse priorité) pour processus réguliers
� Facteur ≈ 3× pour différence de nice de 5
� Priorité temps réel entre 0 et 99 (nice de 0 correspond à priorité de 120)
� Completely Fair Scheduler (CFS) : quantum variable
� Quantum variable pour chaque exécution de processus
� Juste part calculée selon priorité (nice) du processus
� Valeur du quantum dépend des ressources consommées jusqu’à présent par le processus
relativement à sa juste part
� Processus avec part consommée plus faible sont prioritaires
CFS : algorithme d’ordonnancement générique
� Conçu pour fonctionner dans une grande variété de contexte (ex. ordinateur portable,
serveur de calcul, téléphone intelligent)
� Algorithmes d’ordonnancement temps réel également disponibles (présentés semaines
précédentes)
5.1- Noyau Linux
Appels système
Séquence de l’appel à printf()
� Interface POSIX dans la librairie C

� Fonctions système n’ont pas nécessairement à être POSIX
� Mais en pratique tendent à ressembler à POSIX
� POSIX élaboré à partir d’appels système de premières implémentations d’Unix
� Un peu plus de 300 fonctions système dans Linux (noyau 4.0)
5.1- Noyau Linux
Implémentation appels système
Comment sont effectués les appels système ?

� Lancement interruption logicielle 128
� Routine gestion d’interruption d’appel système exécutée
� Appels système effectués par la routine de gestion d’interruption, selon son numéro
� Exécution de l’appel système en mode privilégié
5.1- Noyau Linux
Implémentation appels système
Comment sont effectués les appels système ?

� Lancement interruption logicielle 128
� Routine gestion d’interruption d’appel système exécutée
� Appels système effectués par la routine de gestion d’interruption, selon son numéro
� Exécution de l’appel système en mode privilégié
Chaque appel système est associé à un numéro unique
� Les numéros sont fixes, les changer brise la compatibilité
5.1- Noyau Linux
Temps et compteurs
Comment le temps est géré par le noyau ?
� Interruptions matérielles de l’horloge reçues à fréquence fixe (100Hz pour x86 et ARM),
correspond à un tic
� Interruptions/tics déclenchent traitements périodiques
� Mettre à jour durée d’opération (uptime) du système
� Équilibrer charge des
les de l’ordonnanceur entre processeurs
� Exécuter compteurs dynamiques dont délais sont expirés
� Mettre à jour statistiques sur utilisation des ressources
� Exécution peut être à chaque tic ou bien à chaque n tics
� Fréquence des tics peut être modifiée par recompilation du noyau
� Variable jiffies : nombre de tics depuis démarrage du système
5.1- Noyau Linux
Temps et compteurs
Comment le temps est géré par le noyau ?
� Interruptions matérielles de l’horloge reçues à fréquence fixe (100Hz pour x86 et ARM),
correspond à un tic
� Interruptions/tics déclenchent traitements périodiques
� Mettre à jour durée d’opération (uptime) du système
� Équilibrer charge des
les de l’ordonnanceur entre processeurs
� Exécuter compteurs dynamiques dont délais sont expirés
� Mettre à jour statistiques sur utilisation des ressources
� Exécution peut être à chaque tic ou bien à chaque n tics
� Fréquence des tics peut être modifiée par recompilation du noyau
� Variable jiffies : nombre de tics depuis démarrage du système
Compteur (timer ) : fonction à exécuter après un certain délai
� Appels de fonction ne sont pas périodiques
� Réinsérer compteur après son exécution si modèle périodique désiré
5.1- Noyau Linux
5.1.5- Gestion des entrées/sorties

5.1- Noyau Linux
Interruptions matérielles
Implémentation des interruptions matérielles

� Moitié supérieure (top-half )
� Traitements courts et immédiats
� Ex. lire paquet du tampon de carte réseau les copier en mémoire
� Effectué dans la routine de traitement de l’interruption
� Non-préemptible
5.1- Noyau Linux
Interruptions matérielles
Implémentation des interruptions matérielles

� Moitié supérieure (top-half )
� Traitements courts et immédiats
� Ex. lire paquet du tampon de carte réseau les copier en mémoire
� Effectué dans la routine de traitement de l’interruption
� Non-préemptible
� Moitié inférieure (bottom-half )
� Traitements souvent plus longs et complexes
� Traités par softirqs/tasklets ou
les de travail
� Tasklet : petite tâche placée dans l’ordonnanceur, pour une exécution différée
� File de travail : tâches en attente de traitement par des kthreads
5.1- Noyau Linux
Organisation des E/S
Deux types de dispositifs (devices) d’E/S

� Dispositif de blocs (block device)
� Accès aléatoire à des morceaux de taille fixe
� Ex. disque dur, lecteur optique, mémoire flash
� Dispositif de caractères (character device)
� Flot de données séquentielles
� Ex. port série, clavier
5.1- Noyau Linux

Pour le noyau, dispositif de blocs plus complexe à gérer que dispositif de caractères
� Structure générique interne au noyau pour gérer accès aux dispositifs de blocs
� Requêtes d’accès aux dispositifs de blocs gérées par des files d’attente
5.1- Noyau Linux

Pour le noyau, dispositif de blocs plus complexe à gérer que dispositif de caractères
� Structure générique interne au noyau pour gérer accès aux dispositifs de blocs
� Requêtes d’accès aux dispositifs de blocs gérées par des files d’attente
Ordonnanceur des E/S
� Ordonnanceur distinct pour les E/S à des dispositifs de blocs
� Organise requêtes diverses aux dispositifs de blocs pour maximiser performance
5.1- Noyau Linux
Objectif principal de l’ordonnanceur des E/S : réduire temps d’accès pour augmenter
débit global
� Ordonnanceur peut être injuste à certaines requêtes pour améliorer performance globale
� Principales actions : fusion et tri
� Fusionner requêtes à des emplacements consécutifs sur le dispositif
� Trier file des appels pour optimiser le transfert des données
5.1- Noyau Linux
débit global
Deadline I/O Scheduler
� Chaque requête à une échéance (500ms pour lectures, 5 s pour écritures)
� Trois files d’attente : file de lecture, file d’écriture et file triée
� File triée fusionne et tri les requêtes
� Requêtes insérées dans file de lecture ou file d’écriture (selon l’opération) et dans file triée
� Si requête en tête de file de lecture ou file d’écriture expire, on l’exécute, sinon exécute
requête en tête de file triée
5.1- Noyau Linux
débit global
Deadline I/O Scheduler
� Chaque requête à une échéance (500ms pour lectures, 5 s pour écritures)
� Trois files d’attente : file de lecture, file d’écriture et file triée
� File triée fusionne et tri les requêtes
� Requêtes insérées dans file de lecture ou file d’écriture (selon l’opération) et dans file triée
� Si requête en tête de file de lecture ou file d’écriture expire, on l’exécute, sinon exécute
requête en tête de file triée
Trois autres ordonnanceurs des E/S également présents dans Linux
5.1- Noyau Linux
5.1.6- Linux et systèmes d’exploitation temps réel

5.1- Noyau Linux
Linux et temps réel
Linux : clone ouvert d’Unix

� Implémentation ouverte d’un noyau
� Développement par une communauté de volontaires, valorisant le mérite
� Intégration de l’environnement GNU offrant base Unix
� Écosystème riche avec librairies diverses, développé selon la philosophie Unix
5.1- Noyau Linux

À l’origine, Linux n’était pas conçu pour le temps réel
� Améliorations graduelles permettant le temps réel doux
� Ordonnanceurs de processus temps réel
� Noyau préemptif (patch PREEMPT_RT)
� Différents mécanismes pour réduire variabilités
5.1- Noyau Linux

À l’origine, Linux n’était pas conçu pour le temps réel
� Améliorations graduelles permettant le temps réel doux
� Ordonnanceurs de processus temps réel
� Noyau préemptif (patch PREEMPT_RT)
� Différents mécanismes pour réduire variabilités
D’autres SE disponibles, en particulier pour temps réel dur
5.1- Noyau Linux
QNX
QNX : SE commercial pour temps réel dur

� QNX fondé par étudiants de l’Université de Waterloo (Ontario) au début années 1980,
basé à Ottawa
� Premier SE basé sur micro-noyau ayant connu succès commercial
� Présent dans l’embarqué (voiture, téléphone)
� Acquisition par BlackBerry en 2010
� Reconnaissance comme SE temps réel solide et fiable
5.1- Noyau Linux
QNX
QNX : SE commercial pour temps réel dur

� QNX fondé par étudiants de l’Université de Waterloo (Ontario) au début années 1980,
basé à Ottawa
� Premier SE basé sur micro-noyau ayant connu succès commercial
� Présent dans l’embarqué (voiture, téléphone)
� Acquisition par BlackBerry en 2010
� Reconnaissance comme SE temps réel solide et fiable
Caractéristiques techniques
� Environnement Unix, supporte norme POSIX
� Mécanismes efficaces de communication inter processus basés sur passage de messages
� Communications priorisées selon priorité des threads destinataires
� Évite problèmes d’inversion de priorité
� Deux ordonnanceurs temps réel
5.1- Noyau Linux
FreeRTOS
FreeRTOS : SE ouvert et minimaliste pour systèmes embarqués

� Se résume à trois fichiers sources en C
� Fonctionne sur des plateformes de faible capacité (microcontrôleurs)
� Support pour threads, mutex et compteurs logiciels
� Pas de support pour pilotes de périphériques, comptes utilisateurs, gestion avancée de
la mémoire, réseau, etc.
� Ajout d’extension pour E/S selon API POSIX et interface ligne de commande
5.1- Noyau Linux
FreeRTOS
FreeRTOS : SE ouvert et minimaliste pour systèmes embarqués

� Se résume à trois fichiers sources en C
� Fonctionne sur des plateformes de faible capacité (microcontrôleurs)
� Support pour threads, mutex et compteurs logiciels
� Pas de support pour pilotes de périphériques, comptes utilisateurs, gestion avancée de
la mémoire, réseau, etc.
� Ajout d’extension pour E/S selon API POSIX et interface ligne de commande
SE temps réel autant pour l’académique que le commercial
� Code ouvert et assez simple
� Peut être modifié et adapté aux besoins
� Faible empreinte mémoire
� Surcoûts limités et exécution rapide
5.1- Noyau Linux
Fin de Séance
Vos Questions ?

Noyau Linux - Séance 7

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Noyau Linux - Séance 7

Transféré par

Droits d'auteur :

Formats disponibles

5- Noyau Linux et Développement de Pilotes

Noyau Linux et Développement de Pilotes

Prof. Nabil KANNOUF

5.1- Noyau Linux

5.1.1- Origine de Linux

Qu’est-ce que Linux ?

Vous connaissez tous bien Linux !

Qu’est-ce que Linux ?

Vous connaissez tous bien Linux !

Années 1970 : Développement et adoption d’Unix

Années 1970 : Développement et adoption d’Unix

Années 1970 : Développement et adoption d’Unix

Années 1970 : Développement et adoption d’Unix

Just for fun

Années 1970 : Développement et adoption d’Unix

Logiciel libre et développement collaboratif

Linux est un logiciel libre et développé selon un modèle collaboratif

Logiciel libre et développement collaboratif

Linux est un logiciel libre et développé selon un modèle collaboratif

Logiciel libre et développement collaboratif

Linux est un logiciel libre et développé selon un modèle collaboratif

5.1.2- Philosophie Unix

Règles de la philosophie Unix

Philosophie Unix formalisée plus en détail par Eric S. Raymond

Règles de modularité et de clarté

� Déboggage domine temps de développement

Règles de modularité et de clarté

� Déboggage domine temps de développement

Règles de composition et de séparation

Règles de composition et de séparation

Règles de simplicité et de parcimonie

5 Règle de simplicité : concevoir pour la simplicité ajouter de la complexité seule-

Règles de simplicité et de parcimonie

5 Règle de simplicité : concevoir pour la simplicité ajouter de la complexité seule-

Règles de transparence et de robustesse

7 Règle de transparence : concevoir pour la visibilité aﬁn de rendre inspection et

Règles de transparence et de robustesse

7 Règle de transparence : concevoir pour la visibilité aﬁn de rendre inspection et

Règles de la représentation et de la moindre surprise

9 Règle de la représentation : placer la connaissance dans les données aﬁn de rendre

Règles de la représentation et de la moindre surprise

9 Règle de la représentation : placer la connaissance dans les données aﬁn de rendre

Règles du silence et de la réparation

Règles du silence et de la réparation

Règles de l’économie et de la génération

Règles de l’économie et de la génération

Règles d’optimisation, de diversité et d’extensibilité

15 Règle d’optimisation : prototyper avant de polir ; faire le travail avant de l’optimiser

� Automatiser tâches complexes

Règles d’optimisation, de diversité et d’extensibilité

15 Règle d’optimisation : prototyper avant de polir ; faire le travail avant de l’optimiser

� Automatiser tâches complexes

Règles d’optimisation, de diversité et d’extensibilité

15 Règle d’optimisation : prototyper avant de polir ; faire le travail avant de l’optimiser

� Automatiser tâches complexes

Philosphie Unix en bref

5.1.3- Architecture de noyau

� Serveurs de SE à micro-noyau modernes (ex. Windows NT, Mach) s’exécutent en mode

Noyau monolithique vs micro-noyau

5.1.4- Mécanismes du noyau Linux

Séquence de l’appel à printf()

� Interface POSIX dans la librairie C

Implémentation appels système

Comment sont eﬀectués les appels système ?