1. Développement noyau, drivers sous GNU Linux Thierry GAYET (ALTEN) – 10/2007 – v1.0 – OSP 006 – Creative Common [email_address]

7. L'équipe des développeur au complet " Un travail de longue durée par une équipe de Geeks / Nerds / professionnels passionnés. "

8. Les développeurs du noyau GNU Linux officiels

10. Cycle de développement

11. Acteurs professionnels du noyau Linux http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_history/developer_graph-2.6.18.pdf

12. Croissance exponentielle du noyau GNU Linux Linux est un projet en continuelle évolution…

43. Démarrage d'un système GNU Linux Quand le système démarre (boot ou reboot), le CPU invoque le vecteur de reset de façon à récupérer l'adresse d'un programme localisé à exécuter  Pour un système traditionel, cet emplacement est localisé dans le B.I.O.S. de la carte mère. Quand un device bootable est trouvé, la première étape consiste en un chargement du boot loader en RAM (MBR). Le boot loader doit être d'une taille inférieure ou égale à 512 octets (un seul secteur) et son rôle est de charger en RAM puis d'exécuter la seconde étape (GRUB, LILO, …)‏

44. Démarrage d'un système GNU Linux La seconde étape peut afficher un écran de boot (splashscreen) et crée une zone de mémoire (RAMFS) pour charger le rootfs temporaire depuis l'image Initrd. Une fois cette seconde étape de lancée, charge le noyau linux en mémoire vive puis invoque ce dernier. Par le suite il y a commutation entre le rootfs temporaire et celui qui sera utilisé par la suite (réellement). Après que le noyau soit chargé et initialisé, le noyau démarre en premier la première application de l'espace utilisateur via la libc (/sbin/init) en suivant le numéro défini dans /etc/inittab. Dans Ubuntu, /sbin/init est remplacé par upstart : http://upstart.ubuntu.com/

50. Vue simplifiée d'un diagramme matriciel du noyau GNU Linux 

51. Vue modulaire du noyau GNU Linux 

52. Linux possède plusieurs hypergraphes tel que celui-ci ou bien celui représentant les dépendances des paquets quant à l'établissement d'une distribution conforme LSB (même basique). Vue de l'hypergraphe formé par l'arborescence des sources du noyau 2.4.9  Note : ce schéma n'est pas très lisible mais montre cependant la représentation en oignon (concentrique) du noyau GNU Linux 

54. Linux et le temps réel http://uuu.enseirb.fr/~kadionik/embedded/linux_realtime/linux_realtime9.html http://en.wikipedia.org/wiki/RTLinux http://en.wikipedia.org/wiki/RTAI http://en.wikipedia.org/wiki/Wind_River_Systems http://fr.wikipedia.org/wiki/Xenomai http://www.xenomai.org/index.php/Main_Page http://fr.wikipedia.org/wiki/Xenomai Le noyau Linux n'étant pas Temps réel en natif il est Cependant possible de le Compléter d'un micro-kernel Temps réel où linux est exécuté Comme sous UML, c'est-à-dire sous la forme d'un process 

56. VFS - Virtual File System

57. VFS : Virtual File System Linux n'étant pas monolithique c'est-à-dire qu'il est constitué d'un ensemble de parties comme la pile réseau, la gestion de la mémoire, etc… Bref VFS est la couche d'abstraction de haut niveau intra-kernel regroupant un ensemble de primitives génériques comme open, close, read, write (au nom près). S'il s'agit d'écrire un fichier (une fifo ou autre) sur un disque, hé bien l'implémentation dans le kernel sera la même qu'il s'agisse d'un disque avec un système de fichier cramfs, jffs2 ou 3, ext2 ou 3, reizerfs, etc… VFS est la couche virtuelle qui permet de niveler les appels d'un point de vue noyau ou drivers en se souciant pas du système de fichiers réellement utilisé. En plus de l'API offerte, VFS est un dispatcher sous cette couche, il y a un module spécifique à chaque système de fichiers 

61. Table des systèmes de fichiers courants

63. PM (Process Management)

68. MM (Memory Management)

69. Organisation de la mémoire 0 GB 1 GB Mémoire virtuelle Mémoire physique  Il est possible d'étendre l'utilisation de la mémoire au dela des 4 Go Via l'utilisation de la mémoire haute (ZONE_HIGHMEM). ZONE_NORMAL : KERNEL PHYSICAL SPACE KERNEL VIRTUAL SPACE USER VIRTUAL SPACE 0 GB 3 GB 4 GB http://www.informit.com/content/images/0131453483/downloads/gorman_book.pdf

87. Gestion des entrées/sorties

92. NS (Network Stack)

93. Pile réseau La pile réseau s'interface avec le module VFS et le Process Manager   Pour plus d'information sur la pile réseau, veuillez vous reportez au document "Etude détaillé de la pile réseau sous Linux".

94. SCI (System Call Interface)

97. Pourquoi une méthodologie ? Un kernel panic du noyau GNU linux Le noyau GNU Linux est le cœur du système d'exploitation. Travailler directement au cœur du noyau peut le rendre instable et engendrer un KERNEL PANIC, le rendant donc inutilisable  Avant toute installation d'un nouveau noyau Il est conseillé d'en avoir un autre de référence enregistré au niveau du BOOT loader connu pour ne pas poser de problème lors du démarrage. Développer et surtout tester un nouveau noyau Linux s'accompagne souvent d'un Ensemble de méthodes très utiles.

99. (Dé)chargement de drivers Exemple de listing des modules chargés : $ lsmod (…)‏ snd_pcm_oss 40384 0 snd_mixer_oss 16096 2 snd_pcm_oss (…)‏ En résumé : insmod snd_pcm_oss : OK insmod snd_mixer_oss : OK si snd_pcm_oss déjà chargé sinon NOK modprobe snd_pcm_oss : OK modprobe snd_mixer_oss : OK chargera snd_pcm_oss si pas chargé Le raisonnement est le même pour le déchargement. Seule les commandes changent. rmmod <modulename> remplace insmod et modprobe –r <modulename> remplace modprobe. Modprobe –r, déchargera aussi les autres modules dépendant si non utilisés. modinfo <modulename> donne les informations sur un module comme l'auteur, sa licence, ses paramètres, etc … sudo depmod : permet de recréer le cache de la liste des modules (mécanisme similaire à ldconfig). A noter qu'il est possible de rajouter le nom des modules à charger lors d'un boot dans le fichier de configuration /etc/modules .  Dans le listing suivant, snd_pcm_oss n'as pas de dépendances mais par contre snd_mixer_oss a le module snd_pcm_oss comme dépendance ce qui veut dire qu'il est possible de charger le module snd_pcm_oss de façon unitaire et directement alors que le module snd_mixer_oss nécessitera que le module snd_pcm_oss soit chargé au préalable. Pour info lsmod met en forme les informations générés dans /proc/modules

100. (Dé)chargement de drivers insmod ou modprobe rmmod ou modprobe -r  Lors du chargement dynamique d'un module, cela se passe comme pour le chargement d'une librairie dynamique c'est-à-dire que le module est linké au noyau. Les symboles (primitives) du module sont rajouté et peuvent être utilisés dans d'autres modules ou dans le noyau lui-même.

102. Kernel Mode Linux (KML)‏ http://www.linuxjournal.com/article/6516 http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/ http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/tosh_master_kml_e.ps http://en.wikipedia.org/wiki/Linux_kernel http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/fr/pdf/Kernel-HOWTO.pdf Cette technique réciproque de UML, permet d'exécuter dans le noyau un processus habituellement prévu pour l'espace user. Tout comme pour UML, cela nécessite de patcher le noyau et d'activer la fonctionnalité lors de la Compilation du noyau. Les architectures supportées sont : IA-32 et AMD64. Actuellement, les binaires ne peuvent pas modifier les registres suivants : CS, DS, SS or FS. Ce système peut être cependant intéressant de façon à diminuer la latence : Latency of System Calls (Unit: CPU cycles) : Original Linux (using sysenter) Kernel Mode Linux Getpid 432 12 Gettimeofday 820 404

117. Exemple d'architecture de drivers tty

128. Attributs de périphériques Les attributs du périphériques peuvent être lus/écrits depuis l'espace utilisateur : Exemple : struct device_attribute { struct attribute attr; ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off); ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off); }; #define DEVICE_ATTR(name,mode,show,store)‏ Ajouter / enlever un fichier : int device_create_file(struct device *device, struct device_attribute * entry);