Structure interne du noyau Linux 2.4

Date de mise à jour : 13 mai 2003

Par Tigran Aivazian (mail)
 Yaël Gomez (Adaptation française) (mail)
 Claire Boussard (Relecture de la version française) (mail)
 

Adaptation française du Linux Kernel 2.4 Internals

Une introduction au noyau Linux 2.4. Ce document a été réalisé comme support de cours donnés en interne par l'auteur chez VERITAS Software Ltd. Celui-ci travaille en tant qu'ingénieur senior Noyau Linux au sein de cette société.

I. Introduction

I-A. Dernière version de ce document

I-B. Droits d'utilisation

I-C. Remerciements

• Juan J. Quintela quintela CHEZ fi POINT udc POINT es,
• Francis Galiegue fg CHEZ mandrakesoft POINT com,
• Hakjun Mun juniorm CHEZ orgio POINT net,
• Matt Kraai kraai CHEZ alumni POINT carnegiemellon POINT edu,
• Nicholas Dronen ndronen CHEZ frii POINT com,
• Samuel S. Chessman chessman CHEZ tux POINT org,
• Nadeem Hasan nhasan CHEZ nadmm POINT com,
• Michael Svetlik m.svetlik CHEZ ssi TIRET schaefer TIRET peem POINT com pour les diverses corrections et suggestions.
• Le chapitre Linux Page Cache a été écrit par : Christoph Hellwig hch CHEZ caldera POINT de.
• Le chapitre Mécanismes IPC a été écrit par : Russell Weight weightr CHEZ us POINT ibm POINT com et Mingming Cao mcao CHEZ us POINT ibm POINT com.

I-D. Adaptation française

II. Amorçage (Booting)

II-A. Construire l'image du noyau Linux

1. Les fichiers sources C et assembleur sont compilés au format objet relogeable (.o) ELF et certains d'entre eux sont regroupés logiquement dans des archives (.a) en utilisant ar(1).
2. En utilisant ld(1), les .o et .a ci-dessus sont liés pour donner vmlinux qui est un fichier exécutable ELF 32-bit LSB 80386 non strippé (les symboles n'ont pas été nettoyés), statiquement lié.
3. System.map est produit par nm vmlinux, les symboles inutiles sont retirés.
4. On entre dans le répertoire arch/i386/boot.
5. Le code assembleur du secteur d'amorçage bootsect.S est pré-traité avec ou sans -D__BIG_KERNEL__ pour produire respectivement, selon que la cible est bzImage ou zImage, bbootsect.s ou bootsect.s.
6. bbootsect.s est assemblé et converti en un fichier « binaire brut » (raw binary) appelé bbootsect (ou bootsect.s assemblé et converti en binaire brut donnant bootsect pour zImage).
7. Le code Setup setup.S (setup.S inclut video.S) est pré-traité pour donner bsetup.s pour bzImage ou setup.s pour zImage. De la même façon que pour le code de bootsector, la différence réside en -D__BIG_KERNEL__, présent pour bzImage. Le résultat est converti en un « binaire brut » appelé bsetup.
8. On entre dans le répertoire arch/i386/boot/compressed et convertit /usr/src/linux/vmlinux en $tmppiggy (nom de fichier temporaire) au format binaire brut, en retirant les sections ELF .note et .comment.
9. gzip -9 < $tmppiggy > $tmppiggy.gz
10. On lie $tmppiggy.gz au format ELF relogeable (ld -r) piggy.o.
11. On compile les fonctions de compression head.S et misc.c (toujours dans le répertoire arch/i386/boot/compressed) en objets ELF head.o et misc.o.
12. On lie ensemble head.o, misc.o et piggy.o pour obtenir bvmlinux (ou vmlinux pour zImage, attention à ne pas le confondre avec /usr/src/linux/vmlinux!). Notez la différence entre -Ttext 0x1000 utilisé pour vmlinux et -Ttext 0x100000 pour bvmlinux, i.e. pour bzImage compressé le chargeur (loader) est chargé en haut.
13. On convertit bvmlinux en un « binaire brut » bvmlinux.out en enlevant les sections ELF .note et .comment.
14. On revient dans le répertoire arch/i386/boot et, avec le programme tools/build, concatène bbootsect, bsetup et compressed/bvmlinux.out pour obtenir bzImage (supprimez le « b » du début pour zImage). Ce qui a pour effet d'écrire à la fin du secteur d'amorçage des variables importantes comme setup_sects et root_dev.

II-B. Démarrage : aperçu

1. Le BIOS choisit le périphérique d'amorçage.
2. Le BIOS charge le secteur d'amorçage depuis le périphérique d'amorçage.
3. L'exécution du secteur d'amorçage charge setup, les routines de décompression et l'image compressée du noyau.
4. Le noyau est décompressé en mode protégé.
5. Les initialisations de bas niveau sont réalisées en assembleur.
6. Les initialisations de haut niveau sont réalisées en C.

II-C. Démarrage : BIOS POST

1. L'alimentation démarre le générateur d'horloge et envoie le signal #POWERGOOD sur le bus.
2. La ligne CPU #RESET est positionnée (Le CPU est maintenant en mode réel).
3. %ds=%es=%fs=%gs=%ss=0, %cs=0xFFFF0000,%eip = 0x0000FFF0 (ROM BIOS POST code).
4. Toutes les vérifications POST sont exécutées avec les interruptions désactivées.
5. IVT (Interrupt Vector Table ou table des vecteurs d'interruption) est initialisée à l'adresse 0.
6. La fonction BIOS de chargement du code d'amorçage est invoquée via int 0x19, avec %dl contenant le périphérique d'amorçage « numéro du disque ». Elle charge la piste 0, secteur 1 à l'adresse physique 0x7C00 (0x07C0:0000).

II-D. Démarrage : secteur d'amorçage et lancement

• Le secteur d'amorçage Linux (arch/i386/boot/bootsect.S),
• Le secteur d'amorçage de LILO (ou un autre chargeur d'amorçage), ou
• pas de secteur d'amorçage (loadlin, etc.)

29 SETUPSECS = 4  	    /* défaut pour le nombre de secteurs de lancement */
30 BOOTSEG   = 0x07C0	    /* adresse originelle du secteur d'amorçage */
31 INITSEG   = DEF_INITSEG  /* nous déplaçons l'amorçage ici - hors du chemin */
32 SETUPSEG  = DEF_SETUPSEG /* le lancement démarre ici */
33 SYSSEG    = DEF_SYSSEG   /* le système est chargé à 0x10000 (65536) */
34 SYSSIZE   = DEF_SYSSIZE  /* taille du système~: # en clicks de 16-octets */

/* Ne changez rien ici, sauf si vous savez vraiment ce que vous faites. */
#define DEF_INITSEG     0x9000
#define DEF_SYSSEG      0x1000
#define DEF_SETUPSEG    0x9020
#define DEF_SYSSIZE     0x7F00

54     movw    $BOOTSEG, %ax
55     movw    %ax, %ds
56     movw    $INITSEG, %ax
57     movw    %ax, %es
58     movw    $256, %cx
59     subw    %si, %si
60     subw    %di, %di
61     cld
62     rep
63     movsw
64     ljmp    $INITSEG, $go
     
65  # bde - 0xff00 changé en 0x4000 => permet l'accès débogueur > 0x6400(bde).
66  # Ce ne serait pas un soucis si nous avions testé le haut de la mémoire. La
67  # configuration BIOS peut aussi permettre de placer en mémoire haute les tableaux
68  # des disques wini plutôt que dans le tableau des vecteurs. Il est possible
69  # que l'ancienne pile aie corrompu le tableau des disques.

70 go: movw    $0x4000-12, %di  # 0x4000 est une valeur arbitraire $gt;=
71                              # la longueur du secteur d'amorçage
72                              # + la longueur du setup + laplace pour
73                              # la pile ; 12 est la taille du disk parm.
74     movw    %ax, %ds		# ax et es contiennent déjà INITSEG
75     movw    %ax, %ss
76     movw    %di, %sp		# place la pile à INITSEG:0x4000-12.

1. positionnant %ds:%si sur $BOOTSEG:0 (0x7C0:0 = 0x7C00)
2. positionnant %es:%di sur $INITSEG:0 (0x9000:0 = 0x90000)
3. fixant le nombre de mots de 16 bits dans %cx (256 mots = 512 octets = 1 secteur)
4. réinitialisant le drapeau DF (direction) dans EFLAGS pour auto-incrémenter les adresses (cld)
5. avançant et copiant 512 octets (rep movsw)

77	# La table des paramètres de disque par défaut de nombreux BIOS ne
78	# permet pas la lecture multi-secteurs au-delà du numéro de secteur
79	# maximum spécifié dans le tableau des paramètres par défaut de la
80	# disquette, cela peut signifier 7 secteurs dans certains cas.
81	#
82	# Lire les secteurs un à un est lent et donc hors de question,
83	# nous remédions à cela en créant une table en RAM avec de nouveaux
84	# paramètres (pour le 1er disque). Nous mettons le nb max. de secteurs 
85	# à 36 - nous ne rencontrerons pas plus pour un ED 2.88.  
86	#
87	# Une valeur trop haute ne nuit pas, une trop basse, si.
88	#
89	# Les segments sont comme suit~: ds = es = ss = cs - INITSEG,
90	# fs = 0, et gs est inutilisé.
     
91     movw    %cx, %fs        # met fs à 0
92     movw    $0x78, %bx      # fs:bx est l'adresse du tableau des paramètres
93     pushw   %ds
94     ldsw    %fs:(%bx), %si  # ds:si est la source
95     movb    $6, %cl         # copie 12 octets
96     pushw   %di             # di = 0x4000-12.
97     rep                     # pas besoin de cld -$gt; c'est fait
98     movsw                   # à la ligne 66
99     popw    %di
100    popw    %ds
101    movb    $36, 0x4(%di)   # corrige le compte des secteurs
102    movw    %di, %fs:(%bx)
103    movw    %es, %fs:2(%bx)

107 load_setup:
108    xorb	%ah, %ah		# reset FDC 
109    xorb	%dl, %dl
110    int 	$0x13	
111    xorw	%dx, %dx           # lecteur 0, tête 0
112    movb	$0x02, %cl         # secteur 2, piste 0
113    movw	$0x0200, %bx       # adresse = 512, dans INITSEG
114    movb	$0x02, %ah         # service 2, « lire secteur(s) »
115    movb	setup_sects, %al   # (suppose que tout est tête 0, piste 0)
116    int	$0x13              # lire
117    jnc	ok_load_setup      # ok - continuons
    
118    pushw	%ax                # sort un code d'erreur
119    call	print_nl
120    movw	%sp, %bp
121    call	print_hex
122    popw	%ax	
123    jmp	load_setup
      
124  ok_load_setup:

II-E. Utilisation de LILO comme chargeur d'amorçage (bootloader)

1. La possibilité de choisir entre plusieurs noyaux Linux ou même plusieurs systèmes.
2. La possibilité de passer des paramètres en ligne de commande au noyau (il y a un correctif appelé BCP qui donne cette possibilité à bootsector+setup).
3. La possibilité de charger un noyau bzImage plus grand - jusqu'à 2.5 Mo au lieu de 1 Mo.

II-F. Initialisation de haut niveau

1. Initialisation des valeurs de segments (%ds = %es = %fs = %gs = __KERNEL_DS = 0x18).
2. Initialisation de la table des pages.
3. Activation de la pagination en positionnant le bit PG dans %cr0.
4. Initialisation à zéro de la BSS (sur du multiprocesseur, seul le premier processeur fait cela).
5. Copie des premiers 2 ko des paramètres d'amorçage (ligne de commande du noyau).
6. Vérification du type de CPU en utilisant EFLAGS et, si possible, cpuid, capable de détecter un 386 ou plus.
7. Le premier CPU appelle start_kernel(), tous les autres appellent arch/i386/kernel/smpboot.c:initialize_secondary() si ready=1, qui ne fait que recharger esp/eip et ne retourne pas.

1. Pose un verrou noyau global (c'est nécessaire afin qu'un seul CPU fasse l'initialisation).
2. Effectue les initialisations spécifiques à la plate-forme (analyse de la mémoire, copie une fois encore de la ligne de commande d'amorçage, etc.).
3. Affiche la « bannière » du noyau Linux contenant la version, le compilateur utilisé pour le construire, etc, jusqu'aux messages des tampons noyau. Son contenu est celui de la variable Linux_banner définie dans init/version.c et c'est la même chaîne qui est affichée par cat /proc/version.
4. Initialise les trappes (traps).
5. Initialise les IRQ (Interrupt ReQuest).
6. Initialise les données nécessaires à l'ordonnanceur (scheduler).
7. Initialise les données conservant le temps.
8. Initialise le sous-système d'IRQ logiciel (softirq).
9. Analyse les options de la ligne de commande d'amorçage.
10. Initialise la console.
11. Si le support des modules a été compilé dans le noyau, il initialise les capacités de chargement dynamique des modules.
12. Si la ligne de commande contient « profile= », il initialise les tampons nécessaires.
13. kmem_cache_init(), initialise la plupart du slab allocator (l'allocateur de tranche ?).
14. Active les interruptions.
15. Évalue la vitesse de ce CPU en BogoMips.
16. Appelle mem_init() qui calcule max_mapnr, totalram_pages et high_memory puis affiche la ligne « Memory: ... ».
17. kmem_cache_sizes_init(), finit l'initialisation du slab allocator.
18. Initialise les structures de données utilisées par procfs.
19. fork_init(), crée l'uid_cache, initialise max_threads en fonction de la quantité de mémoire disponible et configure RLIMIT_NPROC pour que init_task soit égal à max_threads/2.
20. Crée les divers caches de type slab nécessaires pour le système de fichiers virtuel, la mémoire virtuelle, le cache tampon, etc.
21. Si le support de la communication interprocessus (IPC System V) est compilé dans le noyau, initialise le sous-système IPC. Remarquez que pour shm System V, cela inclut de monter une instance du système de fichiers shmfs en interne (dans le noyau).
22. Si le support des quotas est compilé dans le noyau, crée et initialise un cache slab spécial pour eux.
23. Effectue les « vérifications de bogues (check for bugs) » spécifiques à l'architecture et, à chaque fois que possible, active les corrections pour les bugs processeur, bus, et cætera. La comparaison de plusieurs architectures révèle que « ia64 n'a pas de bugs » et que « ia32 en a quelques-uns », un bon exemple en est le « bug f00f » qui est testé seulement si le noyau est compilé pour un processeur inférieur au 686 et est alors corrigé.
24. Positionne un drapeau pour indiquer qu'un ordonnancement doit être effectué à la prochaine occasion et crée un thread noyau init() qui va « exec » execute_command si on a un paramètre de boot « init= », ou essayer d'exécuter /sbin/init, /etc/init, /bin/init, /bin/sh dans cet ordre ; si tout échoue, le noyau « panic » et émet la suggestion d'utiliser le paramètre « init= ».
25. Rentre dans une boucle inactive (idle), qui est un fil inactif (idle thread) avec un pid=0.

II-G. Amorçage multiprocesseur (SMP) sur x86

II-H. Libérer les données et le code d'initialisation

• __init - pour le code d'initialisation
• __initdata - pour les données

#ifndef MODULE
#define __init        __attribute__ ((__section__ (".text.init")))
#define __initdata    __attribute__ ((__section__ (".data.init")))
#else
#define __init
#define __initdata
#endif

II-I. Traitement de la ligne de commande du noyau

1. LILO (ou BCP) traite la ligne de commande en utilisant les services clavier du BIOS et la stocke dans un endroit bien repéré de la mémoire physique, avec une signature signifiant qu'il y a une ligne de commande valide ici.
2. arch/i386/kernel/head.S en copie les 2 premiers k vers la page zéro.
3. arch/i386/kernel/setup.c:parse_mem_cmdline() (appelée par setup_arch(), elle même appelée par start_kernel()) copie 256 octets depuis la page zéro dans saved_command_line qui est affiché par /proc/cmdline. Cette même routine traite l'option « mem= » si elle est présente et fait les ajustements nécessaires aux paramètres de la VM.
4. Revenons à la ligne de commande traitée par parse_options() (appelé par start_kernel()) qui traite quelques paramètres « internes au noyau » (actuellement « init= » et l'environnement/arguments pour init) et passe chaque mot à checksetup().
5. checksetup() parcourt le code de la section ELF .setup.init et invoque chaque fonction, lui passant le mot précédent si celui-ci convient. Remarquez qu'en utilisant une valeur de retour de 0 depuis la fonction enregistrée via __setup(), il est possible de passer le même « variable=value » à plus d'une fonction avec « value » invalide pour l'une et valide pour l'autre. Jeff Garzik commente : « les hackers qui font cela s'en mordent les doigts :) ». Pourquoi ? Parce que c'est clairement spécifique à l'ordre d'édition des liens, i.e. un noyau lié dans un sens aura la fonction A appelée avant la fonction B, pour un autre ce sera le contraire, le résultat dépendant de l'ordre.

/*
 * Utilisé pour initialiser les paramètres du noyau avec les valeurs
 * de la ligne de commande
 */
struct kernel_param {
const char *str;
int (*setup_func)(char *);
};

extern struct kernel_param __setup_start, __setup_end;
#ifndef MODULE
#define __setup(str, fn) \
static char __setup_str_##fn[] __initdata = str; \
static struct kernel_param __setup_##fn __initsetup = \
	      { __setup_str_##fn, fn }

#else
#define __setup(str,func) /* rien */
#endif

static int __init
BusLogic_Setup(char *str)
{
int ints[3];
	      
(void)get_options(str, ARRAY_SIZE(ints), ints);
     
if (ints[0] != 0) {
    BusLogic_Error("BusLogic: Obsolete Command Line Entry "
   "Format Ignored\n", NULL);
   return 0;
   }
if (str == NULL || *str == '\0')
   return 0;
   return BusLogic_ParseDriverOptions(str);
   }
	      
__setup("BusLogic=", BusLogic_Setup);

III. Processus et gestion des interruptions

III-A. Structure de tâche et table des processus

/*
* La valeur par défaut du nombre maximum de threads est fixée à une
* valeur sûre~: la structure des threads peut occuper au maximum la moitié
* de la mémoire.
*/
max_threads = mempages / (THREAD_SIZE/PAGE_SIZE) / 2;

# cat /proc/sys/kernel/threads-max 
32764
# echo 100000 $gt; /proc/sys/kernel/threads-max 
# cat /proc/sys/kernel/threads-max 
100000
# gdb -q vmlinux /proc/kcore
Core was generated by `BOOT_IMAGE=240ac18 ro root=306 video=matrox:vesa:0x118'.
#0  0x0 in ?? ()
(gdb) p max_threads
$1 = 100000

1. par une table de hachage, hachée sur le pid, et
2. par une liste circulaire doublement chaînée utilisant les pointeurs p-$gt;next_task et p-$gt;prev_task.

/* Hachage sur le PID. (est-ce que ceci ne devrait pas être dynamique~?) */
#define PIDHASH_SZ (4096 $gt;$gt; 2)
extern struct task_struct *pidhash[PIDHASH_SZ];
     
#define pid_hashfn(x)   ((((x) $gt;$gt; 8) ^ (x)) & (PIDHASH_SZ - 1))

static inline struct task_struct *find_task_by_pid(int pid)
{
struct task_struct *p, **htable = &pidhash[pid_hashfn(pid)];
  
for(p = *htable; p && p-$gt;pid != pid; p = p-$gt;pidhash_next);
 
return p;
}

#define for_each_task(p) \
for (p = &init_task ; (p = p-$gt;next_task) != &init_task ; )

volatile long state;	/* -1 unrunnable, 0 runnable, $gt;0 stopped */

#define TASK_RUNNING            0
#define TASK_INTERRUPTIBLE      1

#define TASK_UNINTERRUPTIBLE    2
#define TASK_ZOMBIE             4
#define TASK_STOPPED            8
#define TASK_EXCLUSIVE          32

1. TASK_RUNNING : signifie que la tâche « est censée être » dans la file d'exécution (runqueue). La raison pour laquelle elle peut ne pas être dans cette file, c'est que le marquage d'une tâche comme TASK_RUNNING et son placement dans la file n'est pas atomique. Il vous faut maintenir le verrou tournant en lecture-écriture runqueue_lock pour lire afin de rechercher dans la file d'exécution . Si vous faite cela vous verrez alors que toutes les tâches dans la file sont dans l'état TASK_RUNNING. Néanmoins, la réciproque n'est pas vraie pour les raisons expliquées précédemment. De la même façon, les pilotes peuvent se marquer eux mêmes (ou plutôt le contexte de processus dans lequel ils s'exécutent) comme TASK_INTERRUPTIBLE (ou TASK_UNINTERRUPTIBLE) et appeler schedule(), qui va alors les retirer de la file d'exécution (sauf s'il y a un signal en attente à leur destination, auquel cas, ils restent dans la file).
2. TASK_INTERRUPTIBLE : signifie que la tâche est endormie mais qu'elle peut être réveillée par un signal ou par l'expiration d'une alarme.
3. TASK_UNINTERRUPTIBLE : idem que TASK_INTERRUPTIBLE, sauf qu'elle ne peut pas être réveillée.
4. TASK_ZOMBIE : la tâche s'est terminée mais son état n'a pas été collecté par son parent (naturel ou par adoption - pas d'appel wait() du parent).
5. TASK_STOPPED : La tâche a été arrêtée, soit par un signal de contrôle des travaux (jobs) soit par ptrace(2).
6. TASK_EXCLUSIVE : Ce n'est pas un état à part entière mais il peut être combiné par un OU (OR) soit à TASK_INTERRUPTIBLE soit à TASK_UNINTERRUPTIBLE. Cela signifie que si cette tâche est endormie dans la file d'attente avec beaucoup d'autres, elle sera la seule à être réveillée, sans réveiller les autres tâches en attente, et provoquer un problème de « thundering herd ».

unsigned long flags;  /* drapeaux pour chaque processus, cf. plus bas */
/*
 * Drapeaux par processus
 */
#define PF_ALIGNWARN  0x00000001    /* Averti des pb d'alignement. Pas encore */
                                    /* implanté, pour 486 seulement */
#define PF_STARTING   0x00000002    /* en création */
#define PF_EXITING    0x00000004    /* en train de s'arrêter */
#define PF_FORKNOEXEC 0x00000040    /* s'est scindé, mais n'a pas encore */
                                    /* fait de « exec  » */
#define PF_SUPERPRIV  0x00000100    /* a utilisé les privilèges de */
                                    /* super-utilisateur */
#define PF_DUMPCORE   0x00000200    /* a laissé un « core dump » */
#define PF_SIGNALED   0x00000400    /* tué par un signal */
#define PF_MEMALLOC   0x00000800    /* en train d'allouer de la mémoire */
#define PF_VFORK      0x00001000    /* réveille le parent dans mm_release */
#define PF_USEDFPU    0x00100000    /* à util. le FPU au cours de ce */
                                    /* quantième (SMP) */

1. le dentry de la racine et le point de montage,
2. un dentry de la racine et un point de montage alternatif,
3. le dentry du répertoire de travail courant et le point de montage.

III-B. Création et terminaison des tâches et des threads noyau

• le(s) thread(s) idle (inutile/inactif),
• les threads noyau,
• les tâches utilisateur.

1. La variable locale retval est mise à -ENOMEM, car c'est la valeur à laquelle errno doit être positionnée si fork(2) échoue lors de l'allocation d'une nouvelle structure de tâche.
2. Si CLONE_PID est positionné dans clone_flags, alors on retourne une erreur (-EPERM), à moins que l'appelant soit le thread inactif (pendant l'amorçage seulement). Donc, un thread utilisateur normal ne peut pas passer CLONE_PID à clone(2) en espérant que ça marche. Pour fork(2), ce n'est pas pertinent, car clone_flags est positionné à SIFCHLD, ça n'est pertinent que lorsque do_fork() est appelé par sys_clone() qui passe alors clone_flags avec la valeur demandée depuis l'espace utilisateur.
3. current-$gt;vfork_sem est initialisé (il sera nettoyé plus tard dans l'enfant). C'est utilisé par sys_vfork() (l'appel système vfork(2) correspond à clone_flags = CLONE_VFORK|CLONE_VM|SIGCHLD) pour que le parent dorme jusqu'à ce que l'enfant fasse mm_release(), par exemple en résultat de l'exec()ution d'un autre programme ou en terminant par exit(2).
4. Une nouvelle structure de tâche est allouée en utilisant la macro spécifique à l'architecture alloc_task_struct(). Sur un x86 c'est juste un gfp à la priorité GFP_KERNEL. C'est la première raison pour laquelle l'appel système fork(2) doit dormir. Si cette allocation échoue, on retourne -ENOMEM.
5. Toutes les valeurs de la structure de tâche du processus courant sont copiées dans la nouvelle structure, en utilisant l'assignation de structure *p = *current. Peut-être que cela devrait être remplacé par un appel à memcopy ? Plus tard, les champs qui ne doivent pas être hérités par le fils seront positionnés aux valeurs correctes.
6. Un GROS verrou de noyau est posé car autrement le reste du code ne serait pas ré-entrant.
7. Si le parent a des ressources utilisateur (un concept d'UID, Linux est suffisamment flexible pour en faire une question plutôt qu'un fait), alors on vérifie si l'utilisateur dépasse la limite douce RLIMIT_NPROC - si c'est le cas, on échoue avec -EAGAIN, sinon, on incrémente le nombre de processus pour l'uid donné p-$gt;user-$gt;count.
8. Si le nombre de tâches du système dépasse la valeur paramétrable fixée par max_threads, on échoue avec -EAGAIN.
9. Si le binaire exécuté appartient à un domaine d'exécution modularisé, on incrémente le compteur de références du module.
10. L'enfant est marqué « non terminé » (p-$gt;did_exec = 0)
11. L'enfant est marqué comme ne pouvant pas être copié en zone d'échange (p-$gt;swappable = 0)
12. L'enfant est placé dans l'état de sommeil sans interruption (uninterruptible sleep), i.e. p-$gt;state = TASK_UNINTERRUPTIBLE (À FAIRE : Pourquoi c'est comme ça ? Je pense que ce n'est pas nécessaire - débarrassez vous en, Linus confirme que c'est inutile)
13. Les p-$gt;flags de l'enfant sont positionnés en fonction de la valeur de clone_flags; pour fork(2), ce sera p-$gt;flags = PF_FORKNOEXEC.
14. Le pid de l'enfant p-$gt;pid est fixé en utilisant un algorithme rapide dans kernel/fork.c:get_pid() (À FAIRE : le verrou tournant lastpid_lock peut être redondant tant que get_pid() est toujours appelé sous le gros verrou du noyau depuis do_fork(), donc je retire les arguments drapeau de get_pid(), le patch à été envoyé à Alan le 20/06/2000).
15. La suite du code dans do_fork() initialise le reste de la structure de tâche de l'enfant. Tout à la fin, cette structure est hachée dans la table de hachage pidhash et l'enfant est réveillé (À FAIRE : wake_up_process(p) positionne p-$gt;state = TASK_RUNNING et ajoute le processus dans la file d'exécution (runq), néanmoins on n'a probablement pas besoin de fixer p-$gt;state à TASK_RUNNING auparavant dans do_fork()). La partie intéressante consiste à mettre p-$gt;exit_signal à clone_flags & CSIGNAL, ce qui pour fork(2) signifie seulement SIGCHLD et fixer p-$gt;pdeath_signal à 0. Le pdeath_signal est utilisé quand un processus « oublie » son parent originel (en mourant) et peut être fixé/obtenu par le biais des commandes PR_GET/SET_PDEATHSIG de l'appel système prctl(2) (Vous pouvez dire que la façon dont la valeur de pdeath_signal est retournée via un argument pointant dans l'espace utilisateur dans prctl(2) est un peu idiote - mea culpa, une fois que Andries Brouwer a eu mis à jour la page man ça a été trop tard pour corriger;)

1. En faisant un appel système exit(2) ;
2. En recevant un signal qui la fait mourir par défaut ;
3. En étant forcée de mourir dans certaines conditions ;
4. En appelant bdflush(2) avec func == 1 (c'est spécifique à Linux, pour la compatibilité avec les vieilles distributions qui ont toujours la ligne « update » dans /etc/inittab - de nos jours le travail de mise à jour est fait par le thread noyau kupdate)

• utilise le verrou global du noyau (elle verrouille mais ne déverrouille pas),
• appelle schedule() à  la fin, qui ne retourne jamais,
• positionne l'état de la tâche à  TASK_ZOMBIE,
• informe tous les enfants en envoyant current-$gt;pdeath_signal, s'il n'est pas nul,
• informe le parent en envoyant current-$gt;exit_signal, qui en général est égal à  SIGCHLD,
• libère les ressources allouées par le fork, ferme les fichiers ouverts, etc,
• sur les architectures qui utilisent « lazy FPU switching » (ia64, mips, mips64) (À FAIRE : retirer l'argument « flags » pour les sparc, sparc64), fait tout ce qu'il faut selon le matériel pour que le propriétaire du FPU (si celui-ci appartient à  la tâche courante) devienne « none » (personne).

III-C. L'ordonnanceur Linux

• p-$gt;need_resched : ce champ est positionné si schedule() doit être appelé « à la prochaine occasion ».
• p-$gt;counter : nombre de tops d'horloge restant dans cette tranche d'ordonnancement, décrémenté par un chronomètre. Quand ce champ devient inférieur ou égal à  zéro, il est remis à  zéro et p-$gt;need_resched est positionné. Cette variable est parfois appelée « dynamic priority » d'un processus car cette priorité change par elle-même.
• p-$gt;priority : priorité statique du processus, elle ne peut être changée que par des appels systèmes répertoriés comme nice(2), sched_setparam(2) POSIX.1b ou setpriority(2) 4.4BSD/SVR4.
• p-$gt;rt_priority : priorité temps réel
• p-$gt;policy : politique d'ordonnancement, spécifie à  quelle classe d'ordonnancement la tâche appartient. Les tâches peuvent modifier leur classe d'ordonnancement en utilisant l'appel système sched_setscheduler(2). Les valeurs reconnues sont SCHED_OTHER (processus UNIX traditionnel), SCHED_FIFO (processus FIFO temps réel POSIX.1b) et SCHED_RR (processus temps réel POSIX utilisant l'algorithme round-robin). On peut aussi faire SCHED_YIELD OU l'une de ces valeurs pour indiquer que c'est le processus qui décide de libérer le CPU, par exemple en invoquant l'appel système sched_yield(2). Un processus FIFO (premier arrivé, premier servi) temps réel tournera jusqu'à ce que : a) il soit bloqué par une entrée/sortie, b) il libère explicitement le CPU ou c) il soit préempté par un autre processus temps réel avec une valeur de priorité p-$gt;rt_priority plus importante. Pour SCHED_RR c'est la même chose que pour SCHED_FIFO, sauf que lorsque la tranche de temps expire il retourne à  la fin de la file d'exécution (runqueue).

1. Si current-$gt;active_mm == NULL alors quelque chose est faux. Le processus courant, même un thread noyau (current-$gt;mm == NULL) doit avoir un p-$gt;active_mm valide en permanence.
2. S'il y a quelque chose à traiter dans la file de tâches tq_scheduler, le faire maintenant. La file de tâches fournit au noyau un mécanisme pour ordonnancer l'exécution ultérieurs de fonctions. On détaillera cela par la suite.
3. Initialiser les variables locales prev et this_cpu respectivement pour la tâche et le CPU courants.
4. Vérifier si schedule() a été appelé par le gestionnaire d'interruption (suite à  un bug) et panique si c'est le cas.
5. Libérer le verrou global du noyau.
6. S'il y a un travail à réaliser par IRQ logiciel (softirq), le faire maintenant.
7. Initialiser le pointeur local struct schedule_data *sched_data pour le faire pointer sur la zone des données d'ordonnancement par CPU (cacheline-aligné pour éviter le cacheline ping-pong) qui contient la valeur TSC de last_schedule et le pointeur vers la dernière structure de tâche ordonnancée (À FAIRE : sched_data n'est utilisé que pour le multiprocesseur (SMP) alors pourquoi init_idle() l'initialise-t-il aussi sur de l'uniprocesseur ?).
8. Un verrou tournant runqueue_lock est posé. Remarquez que nous utilisons spin_lock_irq() car dans schedule() on est sûr que les interruptions sont activées. Par conséquent, quand on déverrouille runqueue_lock, il n'y a qu'à  les réactiver au lieu de sauver/restaurer eflags (variante spin_lock_irqsave/restore).
9. La machine d'état de la tâche : si la tâche est dans un état TASK_RUNNING, on n'y touche pas ; si elle est dans un état TASK_INTERRUPTIBLE et qu'un signal est suspendu elle est placée dans l'état TASK_RUNNING. Dans tous les autres cas elle est effacée de la file d'exécution.
10. next (suivant - le meilleur candidat à  l'ordonnancement) prend pour valeur la tâche idle de notre CPU. Néanmoins, la qualité de ce candidat est mise à  une valeur très basse (-1000), dans l'espoir de trouver un meilleur candidat.
11. Si la tâche prev (courante) est dans un état TASK_RUNNING, alors la qualité courante est fixée à sa qualité et cette tâche est marquée comme meilleur candidat à ordonnancer que la tâche idle.
12. Maintenant la queue d'exécution est examinée et les qualités de chaque processus susceptible d'être ordonnancé sur ce CPU sont comparées à la valeur courante ; le processus qui a la qualité la plus haute gagne. Maintenant le concept de « susceptible d'être ordonnancé sur ce CPU » doit être éclairci : sur de l'UP, chaque processus de la queue d'exécution est éligible pour être ordonnancé; sur du multiprocesseur, seuls les processus qui ne sont pas en cours d'exécution sur un autre CPU sont éligibles pour être ordonnancés sur ce CPU. La qualité est calculée au moyen d'une fonction appelée goodness(), qui fixe très haut la qualité des processus temps réel (1000 + p-$gt;rt_priority), une valeur supérieure à 1000 garantit qu'aucun processus SCHED_OTHER ne peut gagner ; donc ils ne sont en compétition qu'avec d'autres processus temps réel ayant une plus grande priorité p-$gt;rt_priority. La fonction goodness retourne 0 si la tranche de temps (process time slice) du processus (p-$gt;counter) est terminée. Pour des processus non temps réel, la valeur initiale de la qualité est fixée à  p-$gt;counter - de cette façon, le processus a moins de chances d'avoir le CPU s'il l'a déjà eu récemment, i.e. les processus interactifs sont plus favorisés que les mangeurs de CPU. La constante spécifique à  l'architecture PROC_CHANGE_PENALTY essaie d'implémenter « l'affinité CPU » (i.e. donner l'avantage à  un processus du même CPU). Cela donne aussi un léger avantage aux processus ayant mm pointant sur le active_mm courant ou aux processus sans espace d'adressage (utilisateur), i.e. les threads noyau.
13. si la valeur courante de la qualité est 0 alors la liste complète des processus (pas seulement ceux de la queue d'exécution!) est examinée et leurs priorités dynamiques sont recalculées par un algorithme simple : recalculate: { struct task_struct *p; spin_unlock_irq(&#38;runqueue_lock); read_lock(&#38;tasklist_lock); for_each_task(p) p-$gt;counter = (p-$gt;counter $gt;$gt; 1) + p-$gt;priority; read_unlock(&#38;tasklist_lock); spin_lock_irq(&#38;runqueue_lock); } Remarquez que l'on enlève le verrou runqueue_lock avant de recalculer. La raison en est que nous devons traiter l'ensemble des processus, ce qui peut prendre un long moment, durant lequel schedule() peut être appelée sur un autre CPU et choisir un processus avec une qualité satisfaisante pour ce CPU, pendant que nous sur ce CPU on est forcé de recalculer. Ok, de l'aveu général c'est un inconvénient parce que pendant qu'on (sur ce CPU) choisit un processus avec la meilleure qualité, schedule() s'exécutant sur un autre CPU peut recalculer les priorités dynamiques.
14. A partir de ce moment on est certain que next pointe sur la tâche à  ordonnancer, donc on initialise next-$gt;has_cpu à  1 et next-$gt;processor à  this_cpu. Le runqueue_lock peut être levé.
15. Si on rebascule sur la même tâche (next == prev) alors on peut simplement réacquérir le verrou global du noyau et retourner, sans avoir à  traiter tout ce qui concerne le matériel (registres, pile etc.) ni ce qui est lié à  la VM (changer le répertoire de page, recalculer active_mm etc.).
16. La macro switch_to() est spécifique à  l'architecture. Sur un i386, cela concerne a) la gestion du FPU, b) la gestion de la LDT, c) le rechargement des registres de segment, d) la gestion de la TSS et e) le rechargement des registres de déboguage.

III-D. Implémentation des listes chaînées Linux

struct list_head {
    struct list_head *next, *prev;
    };

#define LIST_HEAD_INIT(name) { &(name), &(name) }

#define LIST_HEAD(name) \
        struct list_head name = LIST_HEAD_INIT(name)

#define INIT_LIST_HEAD(ptr) do { \
        (ptr)-$gt;next = (ptr); (ptr)-$gt;prev = (ptr); \
} while (0)

#define list_entry(ptr, type, member) \
        ((type *)((char *)(ptr)-(unsigned long)(&((type *)0)-$gt;member)))

#define list_for_each(pos, head) \
        for (pos = (head)-$gt;next; pos != (head); pos = pos-$gt;next)

struct super_block {
   ...
   struct list_head s_files;
   ...
} *sb = &some_super_block;

struct file {
   ...
   struct list_head f_list;
   ...
} *file;

struct list_head *p;

for (p = sb-$gt;s_files.next; p != &sb-$gt;s_files; p = p-$gt;next) {
     struct file *file = list_entry(p, struct file, f_list);
     do something to 'file'
}

static LIST_HEAD(runqueue_head);
struct list_head *tmp;
struct task_struct *p;

list_for_each(tmp, &runqueue_head) {
    p = list_entry(tmp, struct task_struct, run_list);
    if (can_schedule(p)) {
        int weight = goodness(p, this_cpu, prev-$gt;active_mm);
        if (weight $gt; c)
            c = weight, next = p;
    }
}

static inline void del_from_runqueue(struct task_struct * p)
{
        nr_running--;
        list_del(&p-$gt;run_list);
        p-$gt;run_list.next = NULL;
}

static inline void add_to_runqueue(struct task_struct * p)
{
        list_add(&p-$gt;run_list, &runqueue_head);
        nr_running++;
}

static inline void move_last_runqueue(struct task_struct * p)
{
        list_del(&p-$gt;run_list);
        list_add_tail(&p-$gt;run_list, &runqueue_head);
}

static inline void move_first_runqueue(struct task_struct * p)
{
        list_del(&p-$gt;run_list);
        list_add(&p-$gt;run_list, &runqueue_head);
}

III-E. Les files d'attente (Wait Queues)

static DECLARE_WAIT_QUEUE_HEAD(rtc_wait);

void rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
	spin_lock(&rtc_lock);	
	rtc_irq_data = CMOS_READ(RTC_INTR_FLAGS);
	spin_unlock(&rtc_lock);	
	wake_up_interruptible(&rtc_wait);
}

ssize_t rtc_read(struct file file, char *buf, size_t count, loff_t *ppos)
{
	DECLARE_WAITQUEUE(wait, current);
	unsigned long data;
	ssize_t retval;

	add_wait_queue(&rtc_wait, &wait);
	current-$gt;state = TASK_INTERRUPTIBLE;
	do {
		spin_lock_irq(&rtc_lock);
		data = rtc_irq_data;
		rtc_irq_data = 0;
		spin_unlock_irq(&rtc_lock);

		if (data != 0)
			break;

		if (file-$gt;f_flags & O_NONBLOCK) {
			retval = -EAGAIN;
			goto out;

		}
		if (signal_pending(current)) {
			retval = -ERESTARTSYS;
			goto out;
		}
		schedule();
	} while(1);
	retval = put_user(data, (unsigned long *)buf);	
	if (!retval)
		retval = sizeof(unsigned long);

out:
	current-$gt;state = TASK_RUNNING;
	remove_wait_queue(&rtc_wait, &wait);
	return retval;
}

1. On déclare un élément de file d'attente pointant sur le contexte du processus courant.
2. On ajoute cet élément à  la file d'attente rtc_wait.
3. On marque le contexte courant comme TASK_INTERRUPTIBLE ce qui signifie qu'il ne sera pas réordonnancé à  la fin de son prochain temps de sommeil.
4. On vérifie s'il y a des données disponibles ; s'il y en a, on s'interrompt, on copie les données dans le tampon utilisateur, on se marque TASK_RUNNING, on se retire nous même de la file d'attente et on retourne.
5. S'il n'y a pas encore de données, on regarde si l'utilisateur a spécifié une entrée/sortie non bloquante et si oui on échoue avec EAGAIN (qui est la même chose que EWOULDBLOCK)
6. Nous regardons également s'il y a un signal suspendu et si tel est le cas on demande aux « couches supérieures » de relancer l'appel système si nécessaire. Par « si nécessaire » je pense aux détails de la disposition du signal tels que spécifiés lors de l'appel système sigaction(2).
7. Alors on « bascule hors de la tâche (switch out) », i.e. on s'endort, jusqu'à  ce qu'on soit réveillé par la routine d'interruption. Si on ne s'est pas marqué nous même comme TASK_INTERRUPTIBLE, alors l'ordonnanceur peut nous ordonnancer avant que les données soient disponibles, ce qui cause des traitements inutiles.

static unsigned int rtc_poll(struct file *file, poll_table *wait)
{
        unsigned long l;

        poll_wait(file, &rtc_wait, wait);

        spin_lock_irq(&rtc_lock);
        l = rtc_irq_data;
        spin_unlock_irq(&rtc_lock);


        if (l != 0)
                return POLLIN | POLLRDNORM;
        return 0;
}

III-F. Les chronomètres du noyau (timers)

struct timer_list {
        struct list_head list;
        unsigned long expires;
        unsigned long data;
        void (*function)(unsigned long);
        volatile int running;
};

III-G. Bouts de listes (Bottom Halves)

• void init_bh(int nr, void (*routine)(void)) : installe le gestionnaire de bottom half pointé par l'argument routine à  l'emplacement nr. Les emplacements sont énumérés dans include/linux/interrupt.h sous la forme XXXX_BH, i.e. TIMER_BH ou TQUEUE_BH. Typiquement, une fonction d'initialisation d'un sous-système (init_module() pour les modules) installe les bottom half requis en utilisant cette fonction.
• void remove_bh(int nr) : fait le contraire de init_bh(), i.e. elle désinstalle le bottom half installé à  l'emplacement nr. Il n'y pas de vérification d'erreur effectuée ici, alors, par exemple remove_bh(32) va faire paniquer (panic/Oops) le système. Typiquement, une routine de nettoyage d'un sous-système (cleanup_module() pour modules) utilise cette fonction pour libérer son emplacement qui pourra être réutilisé plus tard par un autre sous-système. (À FAIRE : ne serait il pas bien d'avoir un /proc/bottom_halves listant tous les bottom halves enregistrés sur le système ? Ce qui signifie que global_bh_lock doit être mis en lecture/écriture, évidemment)
• void mark_bh(int nr) : marque le bottom half à  l'emplacement nr pour exécution. Typiquement, une routine d'interruption marquera son bottom half (d'où le nom!) pour exécution à  un « moment plus sûr ».

III-H. Les files de tâches (Task Queues)

1. Il y en a seulement un certain nombre (32).
2. Chaque bottom half peut être associé à  un seul gestionnaire.
3. Les bottom halves sont dévorées par le verrou tournant mis pour qu'elles ne puissent pas bloquer.

1. tq_timer : la file de tâche des chronomètres, s'exécute à chaque interruption de chronomètre et quand on libère un périphérique tty (fermeture ou libération d'un périphérique terminal à demi ouvert). Tant que le gestionnaire de chronomètre s'exécute dans un contexte d'interruption, la tâche tq_timer s'exécute aussi dans un contexte d'interruption et donc ne peut pas bloquer.
2. tq_scheduler : la file de tâche de l'ordonnanceur, exécutée par l'ordonnanceur (et aussi quand on ferme un périphérique tty, comme tq_timer). Comme l'ordonnanceur a été exécuté dans le contexte du processus étant réordonnancé, les tâches de tq_scheduler peuvent faire ce quelles veulent, i.e. bloquer, utiliser les données du contexte processus (mais pourquoi voudraient-elles le faire), et cætera.
3. tq_immediate : c'est un vrai bottom half IMMEDIATE_BH, donc les pilotes peuvent queue_task(task, &tq_immediate) (mettre une tâche dans la file) puis mark_bh(IMMEDIATE_BH) (la marquer) pour être exécutée dans un contexte d'interruption.
4. tq_disk : utilisé par les accès bas niveau aux périphériques bloc (et RAID) pour lancer les requêtes effectives. Cette file de tâches est exportée vers les modules mais ne doit être utilisée que dans les buts précis pour lesquels elle a été conçue.

III-I. Mini-tâches (Tasklets)

III-J. IRQ logicielles (softirq)

III-K. Comment les appels système sont-ils implémentés sur une architecture i386 ?

• Les portes d'appel (call gates) lcall7/lcall27;
• l'interruption logicielle int 0x80.

1. il sauvegarde les registres ;
2. il positionne %ds et %es à  KERNEL_DS, pour que toutes les références aux données (et autres segments) soient faites dans l'espace d'adressage du noyau ;
3. si la valeur de %eax est supérieure à  NR_syscalls (actuellement 256), il échoue avec l'erreur ENOSYS ;
4. si la tâche est tracée (tsk-$gt;ptrace & PF_TRACESYS), il fait un traitement spécial, ceci pour supporter des programmes comme strace (analogue à  truss(1) dans SVR4) ou les débogueurs ;
5. il appelle sys_call_table+4*(syscall_number de %eax). Cette table est initialisée dans le même fichier (arch/i386/kernel/entry.S) pour pointer individuellement sur les gestionnaire d'appels systèmes, lesquels sous Linux sont (généralement) préfixés par sys_, i.e. sys_open, sys_exit, et cætera. Ces gestionnaires d'appels systèmes C vont trouver leurs arguments dans la pile où SAVE_ALL les a stockés.
6. il entre dans le « chemin de retour de l'appel système ». C'est un label séparé car il n'est pas utilisé seulement par int 0x80 mais aussi par lcall7, lcall27. Il est chargé des mini-tâches (incluant les bottom halves), de vérifier si un schedule() est nécessaire (tsk-$gt;need_resched != 0), de vérifier s'il y a des signaux suspendus et dans ce cas de les traiter.

III-L. Opérations atomiques

/*
 *  Nb de bits dans microcode_status. (31 bits de plus pour le futur)
 */
#define MICROCODE_IS_OPEN  0  /* positionné lorsque le périphérique */
                              /* est utilisé */

static unsigned long microcode_status;

/*
 * Nous n'autorisons ici qu'un seul utilisateur à la fois pour ouvrir/fermer.
 */
static int microcode_open(struct inode *inode, struct file *file)
{
        if (!capable(CAP_SYS_RAWIO))
                return -EPERM;

        /* one at a time, please */
        if (test_and_set_bit(MICROCODE_IS_OPEN, &microcode_status))
                return -EBUSY;

        MOD_INC_USE_COUNT;
        return 0;
}

• void set_bit(int nr, volatile void *addr) : fixe le bit nr dans le bitmap pointé par addr.
• void clear_bit(int nr, volatile void *addr) : met à 0 le bit nr dans le bitmap pointé par addr.
• void change_bit(int nr, volatile void *addr) : change le bit nr (s'il est positionné (1), on le met à  0, s'il ne l'est pas, on le positionne) dans le bitmap pointé par addr.
• int test_and_set_bit(int nr, volatile void *addr) : positionne le bit nr atomiquement et retourne l'ancienne valeur.
• int test_and_clear_bit(int nr, volatile void *addr) : met à  0 le bit nr atomiquement et retourne l'ancienne valeur.
• int test_and_change_bit(int nr, volatile void *addr) : change le bit nr atomiquement et retourne l'ancienne valeur.

• atomic_read(&v) : lit la valeur de la variable atomic_t v,
• atomic_set(&v, i) : fixe la valeur de la variable atomic_t v à  l'entier i,
• void atomic_add(int i, volatile atomic_t *v) : ajoute l'entier i à  la valeur de la variable atomique pointée par v,
• void atomic_sub(int i, volatile atomic_t *v) : soustrait l'entier i de la valeur de la variable atomique pointée par v,
• int atomic_sub_and_test(int i, volatile atomic_t *v) : soustrait l'entier i de la valeur de la variable atomique pointée par v ; retourne 1 si la nouvelle valeur est 0, retourne 0 autrement.
• void atomic_inc(volatile atomic_t *v) : incrémente la valeur de 1.
• void atomic_dec(volatile atomic_t *v) : décrémente la valeur de 1.
• int atomic_dec_and_test(volatile atomic_t *v) : décrémente la valeur ; retourne 1 si la nouvelle valeur est 0, retourne 0 sinon.
• int atomic_inc_and_test(volatile atomic_t *v) : incrémente la valeur ; retourne 1 si la nouvelle valeur est 0, retourne 0 sinon.
• int atomic_add_negative(int i, volatile atomic_t *v) : ajoute la valeur de i à  v et retourne 1 si le résultat est négatif. Retourne 0 si le résultat est supérieur ou égal à  0. Cette opération est utilisée pour implémenter les sémaphores.

III-M. Verrous tournants, verrous tournants en lecture/écriture et verrous tournants gros lecteurs

unsigned long flags;

save_flags(flags);
cli();
/* critical code */
restore_flags(flags);

1. spin_lock()/spin_unlock() simple : si vous savez que les interruptions sont toujours inactivées ou si vous n'êtes pas en concurrence avec des contextes d'interruption (i.e. depuis un gestionnaire d'interruption), alors vous pouvez les utiliser. Ils ne touchent pas à  l'état d'interruption du CPU courant.
2. spin_lock_irq()/spin_unlock_irq() : si vous savez que les interruptions sont toujours activées, alors vous pouvez utiliser cette version, qui simplement désactive (au verrouillage) et réactive (au déverrouillage) les interruptions sur le CPU courant. Par exemple, rtc_read() utilise spin_lock_irq(&rtc_lock) (les interruptions sont toujours activées dans read()) alors que rtc_interrupt() utilise spin_lock(&rtc_lock) (les interruptions sont toujours désactivées dans le gestionnaire d'interruption). Remarquez que rtc_read() utilise spin_lock_irq() et pas le plus générique spin_lock_irqsave() parce que les interruptions sont toujours activées lorsqu'on entre dans n'importe quel appel système, .
3. spin_lock_irqsave()/spin_unlock_irqrestore() : la forme la plus robuste, à  utiliser quand l'état d'interruption n'est pas connu, mais seulement si les interruptions ont de l'importance, i.e. il n'y a pas de raison de l'utiliser si nos gestionnaires d'interruption n'exécutent pas de code critique.

spinlock_t my_lock = SPIN_LOCK_UNLOCKED;

my_ioctl()
{
	spin_lock_irq(&my_lock);
	/* section critique */
	spin_unlock_irq(&my_lock);
}

my_irq_handler()
{
	spin_lock(&lock);
	/* section critique */
	spin_unlock(&lock);
}

1. Le contexte de processus, représenté ici par une méthode typique de pilote - ioctl() (les arguments et les valeurs de retour ont été omis pour simplifier), doit utiliser spin_lock_irq() parce qu'il sait que les interruptions sont toujours activées pendant l'exécution de la méthode ioctl() du périphérique.
2. Le contexte d'interruption, représenté ici par my_irq_handler() (on omet encore les arguments par souci de clarté) peut utiliser la forme simple spin_lock() parce que les interruptions sont désactivées à l'intérieur du gestionnaire d'interruption.

III-N. Les sémaphores et les sémaphores en lecture/écriture

asmlinkage long sys_sethostname(char *name, int len)
{
        int errno;

        if (!capable(CAP_SYS_ADMIN))
                return -EPERM;
        if (len $lt; 0 || len $gt; __NEW_UTS_LEN)
                return -EINVAL;
        down_write(&uts_sem);
        errno = -EFAULT;
        if (!copy_from_user(system_utsname.nodename, name, len)) {
                system_utsname.nodename[len] = 0;
                errno = 0;
        }
        up_write(&uts_sem);
        return errno;
}

asmlinkage long sys_gethostname(char *name, int len)
{
        int i, errno;

        if (len $lt; 0)
                return -EINVAL;
        down_read(&uts_sem);
        i = 1 + strlen(system_utsname.nodename);
        if (i $gt; len)
                i = len;
        errno = 0;
        if (copy_to_user(name, system_utsname.nodename, i))
                errno = -EFAULT;
        up_read(&uts_sem);
        return errno;
}

1. Les fonctions peuvent bloquer pendant la copie de donnée depuis/vers l'espace utilisateur dans copy_from_user()/copy_to_user(). Donc elles ne peuvent utiliser aucune forme de verrou tournant ici.
2. Le type de sémaphore choisi est lecture-écriture plutôt que basique parce qu'il peut y avoir beaucoup de requêtes gethostname(2) concurrentes qui n'ont pas besoin d'être mutuellement exclusives.

III-O. Le support noyau des modules chargeables

1. Pilotes de périphériques caractère et bloc, incluant des pilotes de périphérique divers.
2. Les disciplines des lignes de terminal.
3. Les fichiers virtuels (réguliers) dans /proc et dans devfs (i.e. /dev/cpu/microcode vs /dev/misc/microcode).
4. Les formats des fichiers binaires (i.e. ELF, aout, et cætera).
5. Les domaines d'exécution (i.e. Linux, UnixWare7, Solaris, et cætera).
6. Les systèmes de fichiers.
7. Les communications inter processus System V.

1. les algorithmes d'ordonnancement,
2. les politiques de la VM (mémoire virtuelle),
3. le cache tampon (Buffer cache), le cache de page (page cache) et les autres caches.

1. caddr_t create_module(const char *name, size_t size) : alloue size octets en utilisant vmalloc() et place une structure de module au début de ceux ci. Ce nouveau module est ensuite lié à  la liste commençant par module_list. Seul un processus avec CAP_SYS_MODULE peut invoquer cet appel système, les autres se verront retourner EPERM.
2. long init_module(const char *name, struct module *image) : charge et reloge l'image du module, ce qui provoque l'appel de la fonction d'initialisation du module. Seul un processus avec CAP_SYS_MODULE peut invoquer cet appel système, les autres se verront retourner EPERM.
3. long delete_module(const char *name) : essaie de décharger le module. Si name == NULL, essaie de décharger tous les modules inutilisés.
4. long query_module(const char *name, int which, void *buf, size_t bufsize, size_t *ret) : renvoie les informations concernant un module (ou concernant tous les modules).

• insmod : insère un module seul.
• modprobe : insère un module en incluant tous les modules dont il dépend.
• rmmod : retire un module.
• modinfo : affiche des informations concernant le module, i.e. auteur, description, paramètres du module, et cætera.

if (check_some_feature() == NULL)
    request_module(module);
if (check_some_feature() == NULL)
    return -ENODEV;

static struct file_system_type *get_fs_type(const char *name)
{
        struct file_system_type *fs;

        read_lock(&file_systems_lock);
        fs = *(find_filesystem(name));
        if (fs && !try_inc_mod_count(fs-$gt;owner))
                fs = NULL;
        read_unlock(&file_systems_lock);
        if (!fs && (request_module(name) == 0)) {
                read_lock(&file_systems_lock);
                fs = *(find_filesystem(name));
                if (fs && !try_inc_mod_count(fs-$gt;owner))
                        fs = NULL;
                read_unlock(&file_systems_lock);
        }
        return fs;
}

1. D'abord on essaie de trouver le système de fichier dont le nom est donné parmi ceux déjà  enregistrés. C'est fait sous la protection de file_systems_lock posé pour lire (nous ne sommes pas en train de modifier la liste de systèmes de fichier enregistrés).
2. Si un tel système de fichier est trouvé, alors on essaie d'obtenir une nouvelle référence sur lui en incrémentant le compteur maintenu par le module. Ce qui retourne toujours 1 pour les modules liés statiquement ou pour les modules qui ne sont pas enlevés du noyau. Si try_inc_mod_count() retourne 0, alors on considère que c'est une erreur - i.e. si le module est là  mais en train d'être retiré, c'est pareil que s'il n'était pas là  du tout.
3. Nous enlevons le file_systems_lock parce que l'opération suivante (request_module()) sera une opération bloquante, donc on ne peut pas maintenir un verrou tournant dessus. Maintenant, dans ce cas particulier, il aurait fallu enlever le file_systems_lock de toutes façons, même en étant sûr que request_module() ne soit pas bloquant et que le chargement du module s'exécute atomiquement dans le même contexte. C'est parce que la fonction d'initialisation du module va tenter d'appeler register_filesystem(), qui va poser le même verrou tournant en lecture-écriture file_systems_lock pour écrire.
4. Si l'essai de chargement est réussi, alors on pose le verrou tournant file_systems_lock et on essaie de localiser le système de fichiers nouvellement enregistré dans la liste. Remarquez que c'est un peu faux parce qu'il est en principe possible pour un bug dans la commande modprobe de causer un coredump après avoir réussi à  charger le module demandé, dans ce cas request_module() va échouer même si le nouveau système de fichiers est enregistré, et get_fs_type() ne le trouvera pas.
5. Si le système de fichier est trouvé et que nous sommes capables d'obtenir une référence sur lui, on la retourne. Autrement on renvoie NULL.

IV. Système de fichiers virtuel (Virtual Filesystem : VFS)

IV-A. Le cache inode et les interactions avec le Dcache

1. Une table de hachage globale, inode_hashtable, où chaque inode est haché sur la valeur du pointeur du super-bloc et le numéro de l'inode codé sur 32 bits. Les inodes sans super-bloc (inode-$gt;i_sb == NULL) sont ajoutés à une liste doublement chaînée ancrée sur anon_hash_chain. Comme exemple d'inodes anonymes, on a les sockets créées par net/socket.c:sock_alloc(), en appelant fs/inode.c:get_empty_inode().
2. Une liste globale du type utilisé (inode_in_use), qui contient les inodes valides avec i_count$gt;0 et i_nlink$gt;0. Les inodes nouvellement alloués par get_empty_inode() et get_new_inode() sont ajoutés à  la liste inode_in_use.
3. Une liste globale du type inutilisé (inode_unused), qui contient les inodes valides avec i_count = 0.
4. Une liste par super-bloc du type modifié (dirty) (sb-$gt;s_dirty) qui contient les inodes valides avec i_count$gt;0, i_nlink$gt;0 et i_state & I_DIRTY. Quand l'inode est marqué modifié, il est ajouté à  la liste sb-$gt;s_dirty s'il est aussi haché. Maintenir une liste d'inodes modifiés par super-bloc permet de synchroniser les inodes rapidement.
5. Un cache inode propre - un cache SLAB appelé inode_cachep. Quand les objets inode sont alloués et libérés, ils sont pris et remis dans le cache SLAB.

(gdb) printf "%d\n", (unsigned long)(&((struct inode *)0)-$gt;i_list)
8
(gdb) p inode_unused
$34 = 0xdfa992a8
(gdb) p (struct list_head)inode_unused
$35 = {next = 0xdfa992a8, prev = 0xdfcdd5a8}
(gdb) p ((struct list_head)inode_unused).prev
$36 = (struct list_head *) 0xdfcdd5a8
(gdb) p (((struct list_head)inode_unused).prev)-$gt;prev
$37 = (struct list_head *) 0xdfb5a2e8
(gdb) set $i = (struct inode *)0xdfb5a2e0
(gdb) p $i-$gt;i_ino
$38 = 0x3bec7
(gdb) p $i-$gt;i_count
$39 = {counter = 0x0}

fd = open("file", O_RDONLY);
close(fd);

1. open_namei() : remplit la structure nameidata contenant les structures dentry et vfsmount.
2. dentry_open() : étant donnés dentry and vfsmount, cette fonction alloue une nouvelle struct file et les lie ensemble ; elle invoque aussi la méthode f_op-$gt;open() spécifique au système de fichiers, qui a été positionnée dans inode-$gt;i_fop lors de la lecture de l'inode dans open_namei() (qui fournit l'inode via dentry-$gt;d_inode).

unsigned long ino = le32_to_cpu(de-$gt;inode);
inode = iget(sb, ino);
d_add(dentry, inode);

1. Essaie de trouver un inode correspondant au super-bloc et un numéro d'inode dans la table de hachage sous la protection de inode_lock. Si l'inode est trouvé, son compteur de références (i_count) est incrémenté; s'il était à  0 avant l'incrémentation et que l'inode n'est pas utilisé, il est retiré de tous les types de liste (inode-$gt;i_list) dont il fait actuellement partie (il doit être dans la liste inode_unused, bien sûr) et inséré dans la liste de type inode_in_use; finalement, inodes_stat.nr_unused est décrémenté.
2. Si l'inode est actuellement verrouillé, on attend qu'il soit déverrouillé pour que iget4() soit sûr de renvoyer un inode non verrouillé.
3. Si l'inode n'a pas été trouvé dans la table de hachage, c'est que nous rencontrons cet inode pour la première fois, donc on appelle get_new_inode(), en lui passant le pointeur sur l'endroit de la table de hachage où l'inode doit être inséré.
4. get_new_inode() alloue un nouvel inode depuis le cache SLAB inode_cachep mais cette opération peut bloquer (allocation GFP_KERNEL), alors elle doit enlever le verrou tournant inode_lock qui protège la table de hachage. Dès qu'elle a enlevé le verrou, elle peut réessayer de chercher l'inode dans la table de hachage ; s'il est trouvé cette fois ci, elle le renvoie (après incrémentation de la référence par __iget) et détruit celui qui a été alloué entre temps. Si elle ne le trouve toujours pas dans la table de hachage, on utilisera le nouvel inode que l'on vient juste d'allouer ; celui-ci est initialisé aux valeurs voulues et la méthode sb-$gt;s_op-$gt;read_inode() spécifique au système de fichiers est invoquée pour renseigner le reste de l'inode. Ce qui nous ramène du cache inode au code du système de fichier - rappelez vous que nous venions du cache inode lorsque la méthode lookup() spécifique au système de fichiers a invoqué iget(). Pendant que la méthode s_op-$gt;read_inode() lit l'inode sur le disque, l'inode est verrouillé (i_state = I_LOCK); il est déverrouillé après le retour de la méthode read_inode() et tous les processus qui l'attendaient sont alors réveillés.

1. Si le paramètre passé est NULL, nous ne faisons rien du tout et nous retournons.
2. S'il y a une méthode sb-$gt;s_op-$gt;put_inode() spécifique au système de fichiers, elle est invoquée immédiatement sans verrou tournant (ainsi elle peut bloquer).
3. Le verrou tournant inode_lock est posé et i_count est décrémenté. Si ce n'était PAS la dernière référence à  cet inode, alors on vérifie simplement qu'il n'y a pas trop de références à  lui auquel cas i_count pourrait boucler autour des 32 bits qui lui sont alloués, et si oui on affiche un avertissement et retourne. Remarquez que l'on appelle printk() pendant que le verrou tournant inode_lock est posé - c'est bien car printk() ne peut jamais bloquer, de plus elle peut être appelée dans absolument tous les contextes (même dans les gestionnaires d'interruption!).
4. Si c'était la dernière référence active, alors il y a encore un peu de travail à  faire.

1. Si i_nlink == 0 (i.e. le fichier a été délié (unlink) pendant qu'il était ouvert) alors l'inode est retiré de la table de hachage et de la liste de son type ; s'il reste des pages de données dans le cache de page pour cet inode, elles sont enlevées au moyen de truncate_all_inode_pages(&inode-$gt;i_data). Puis la méthode spécifique au système de fichiers s_op-$gt;delete_inode() est invoquée, qui, comme son nom l'indique, détruit la copie de l'inode sur le disque. S'il n'y a pas de méthode s_op-$gt;delete_inode() enregistrée dans le système de fichiers (i.e. mémoire (ramfs)) on appelle clear_inode(inode), qui invoque s_op-$gt;clear_inode() si elle est enregistrée et si l'inode correspond à  un périphérique bloc, le compteur de références de ce périphérique est enlevé par bdput(inode-$gt;i_bdev).
2. Si i_nlink != 0, alors on cherche s'il y a d'autres inodes dans la même valeur de hachage et s'il n'y en a pas, c'est que l'inode n'est pas utilisé, on l'efface de la liste de son type et on l'ajoute à  la liste inode_unused, en incrémentant inodes_stat.nr_unused. Si on trouve des inodes pour la même valeur de hachage, on les efface de la liste de leur type et on les ajoute à  la liste inode_unused. Si c'était un inode anonyme (NetApp .snapshot), on l'efface de la liste de son type et on le nettoie/détruit complètement.

IV-B. Enregistrement/dés-enregistrement de systèmes de fichiers

1. Dans un monde où les gens utilisent des systèmes d'exploitation non-Linux pour protéger leur investissement dans des logiciels traditionnels, Linux devait permettre l'interopérabilité en supportant une multitude de systèmes de fichiers différents - la plupart n'ayant pas d'intérêt par eux même mais seulement pour la compatibilité avec des systèmes d'exploitation non-Linux.
2. Pour écrire des systèmes de fichiers, les gens devaient disposer d'une interface très simple pour qu'ils puissent faire de la rétro-ingénierie sur les systèmes de fichiers propriétaires en créant des versions en lecture seule de ceux-ci. En conséquence, le VFS Linux (système de fichiers virtuel) rend vraiment facile l'implémentation de systèmes de fichiers en lecture seule ; 95% du travail réside alors dans l'ajout du support complet en écriture. Pour prendre un exemple concret, j'ai écrit un système de fichiers BFS en lecture seule pour Linux en à  peu près 10 heures, mais il m'a fallu plusieurs semaines pour le terminer et avoir un support complet en écriture (et même aujourd'hui certains puristes se plaignent qu'il n'est pas complet car « il ne supporte pas la compactification »).
3. L'interface VFS est exportée, donc tous les systèmes de fichiers Linux peuvent être implémentés en tant que modules.

#include $lt;linux/module.h$gt;
#include $lt;linux/init.h$gt;


static struct super_block *bfs_read_super(struct super_block *, void *, int);

static DECLARE_FSTYPE_DEV(bfs_fs_type, "bfs", bfs_read_super);

static int __init init_bfs_fs(void)
{
        return register_filesystem(&bfs_fs_type);
}

static void __exit exit_bfs_fs(void)
{
        unregister_filesystem(&bfs_fs_type);
}

module_init(init_bfs_fs)
module_exit(exit_bfs_fs)

struct file_system_type {
        const char *name;
        int fs_flags;
        struct super_block *(*read_super) (struct super_block *, void *, int);
        struct module *owner;
        struct vfsmount *kern_mnt; /* Pour monter le noyau, si c'est un FS_SINGLE fs */
        struct file_system_type * next;
};

• name : nom lisible par un être humain, apparaît dans le fichier /proc/filesystems et est utilisé comme clef pour trouver un système de fichiers par son nom ; ce même nom est utilisé pour le type de système de fichiers dans mount(2), et il doit être unique : il ne peut y avoir (évidemment) qu'un seul système de fichiers pour un nom donné. Pour les modules, name pointe sur l'espace d'adressage du module et n'est pas copié : cela veut dire que cat /proc/filesystems peut planter (oops) si le module a été déchargé mais que le système de fichier est toujours enregistré.
• fs_flags : l'un ou plusieurs (combinés par un OU) des drapeaux : FS_REQUIRES_DEV pour les systèmes de fichiers qui ne peuvent être montés que sur un périphérique bloc, FS_SINGLE pour les systèmes de fichiers qui ne peuvent avoir qu'un super-bloc, FS_NOMOUNT pour les systèmes de fichiers qui ne peuvent pas être montés depuis l'espace utilisateur par l'appel système mount(2) : ils peuvent néanmoins être montés en interne en utilisant l'interface kern_mount(), i.e. pipefs (système de fichiers tube).
• read_super : un pointeur sur la fonction qui lit le super-bloc durant l'opération de montage. Cette fonction est requise : si elle n'est pas fournie, l'opération de montage (soit dans l'espace utilisateur soit à  l'intérieur du noyau) finira toujours par un échec sauf dans le cas FS_SINGLE où il « Oupsera » dans get_sb_single(), en essayant de déréférencer un pointeur NULL dans fs_type-$gt;kern_mnt-$gt;mnt_sb avec (fs_type-$gt;kern_mnt = NULL).
• owner (propriétaire) : pointeur sur le module qui implémente le système de fichiers. Si le système de fichiers est lié statiquement dans le noyau, il vaut NULL. Vous n'avez pas besoin de le fixer manuellement car la macro THIS_MODULE le fait bien, automatiquement.
• kern_mnt : pour les systèmes de fichiers FS_SINGLE. Positionné par kern_mount() (À FAIRE : kern_mount() devrait refuser de monter des systèmes de fichiers si FS_SINGLE n'est pas positionné).
• next : liage dans une liste chaînée simple ancrée sur file_systems (cf fs/super.c). Cette liste est protégée par le verrou tournant en lecture-écriture file_systems_lock et les fonctions register/unregister_filesystem() la modifient en liant et déliant les entrées de la liste.

1. Lira le super-bloc sur le périphérique spécifié via l'argument sb-$gt;s_dev, en utilisant la fonction de cache tampon bread(). S'il prévoit de lire immédiatement d'autres blocs de méta-données consécutifs, alors cela vaut la peine d'utiliser breada() pour ordonnancer la lecture asynchrone de quelques blocs de plus.
2. Vérifiera que le super-bloc contient un nombre magique valide et que l'ensemble « ait l'air » sain.
3. Initialisera sb-$gt;s_op de façon à  ce qu'il pointe sur la structure struct super_block_operations. Cette structure contient les fonctions spécifiques au système de fichiers implémentant des opérations comme « read inode », « delete inode », et cætera.
4. Allouera l'inode racine et le dentry racine en utilisant d_alloc_root().
5. Si le système de fichier est monté en lecture seule alors mettra sb-$gt;s_dirt à  1 et marquera le tampon contenant le super-bloc modifié (À FAIRE : pourquoi est ce que l'on fait ça ? Je l'ai fait dans BFS pour faire comme MINIX_)

IV-C. Gestion des descripteurs de fichier

/*
 * Ouvrir la structure du tableau des fichiers
 */
struct files_struct {
        atomic_t count;
        rwlock_t file_lock;
        int max_fds;
        int max_fdset;
        int next_fd;
        struct file ** fd;      /* tableau fd courant */
        fd_set *close_on_exec;
        fd_set *open_fds;
        fd_set close_on_exec_init;
        fd_set open_fds_init;
        struct file * fd_array[NR_OPEN_DEFAULT];
};

IV-D. Gestion de la structure des fichiers

struct fown_struct {
        int pid;                /* le pid ou -pgrp auquel SIGIO doit être envoyé */
        uid_t uid, euid;        /* uid/euid du processus définissant le propriétaire */
        int signum;             /* le signal posix.1b rt à  envoyer sur l'IO */
};

struct file {
        struct list_head        f_list;
        struct dentry           *f_dentry;
        struct vfsmount         *f_vfsmnt;
        struct file_operations  *f_op;
        atomic_t                f_count;
        unsigned int            f_flags;
        mode_t                  f_mode;
        loff_t                  f_pos;
        unsigned long           f_reada, f_ramax, f_raend, f_ralen, f_rawin;
        struct fown_struct      f_owner;
        unsigned int            f_uid, f_gid;
        int                     f_error;

        unsigned long           f_version;
  
        /* nécessaire pour les pilotes de tty, et peut-être pour d'autres */
        void                    *private_data; 
};

1. f_list : ce champ lie la structure de fichiers à  une (et une seule) de ces listes : a) sb-$gt;s_files, liste de tous les fichiers ouverts sur le système de fichiers, si l'inode correspondant n'est pas anonyme, alors dentry_open() (appelé par filp_open()) lie le fichier à  la liste ; b) fs/file_table.c:free_list, contenant les structures de fichiers inutilisées ; c) fs/file_table.c:anon_list, quand une nouvelle structure de fichier est créée par get_empty_filp(), elle est placée dans cette liste. Toutes ces listes sont protégées par le verrou tournant files_lock.
2. f_dentry : le dentry correspondant à  ce fichier. Le dentry est créé au moment de la vérification nameidata par open_namei() (ou plutôt path_walk() qu'elle appelle) mais l'actuel champs file-$gt;f_dentry est fixé par dentry_open() à  la valeur du dentry trouvé.
3. f_vfsmnt : le pointeur sur la structure vfsmount du système de fichiers contenant le fichier. C'est fixé par dentry_open() mais provient d'une partie du résultat de la recherche de nameidata par open_namei() (ou plutôt path_init() qu'elle appelle).
4. f_op : le pointeur sur file_operations qui contient diverses méthodes qui peuvent être invoquées sur le fichier. C'est copié depuis inode-$gt;i_fop qui a été placé ici par la méthode spécifique au système de fichiers s_op-$gt;read_inode() durant la recherche de nameidata. On regardera les méthodes file_operations en détail plus loin dans ce chapitre.
5. f_count : compteur de références manipulé par get_file/put_filp/fput.
6. f_flags : Les drapeaux O_XXX de l'appel système open(2) copiés ici (avec de légères modifications par filp_open()) par dentry_open() après nettoyage de O_CREAT, O_EXCL, O_NOCTTY, O_TRUNC - il n'y a pas de raison de les stocker en permanence puisqu'ils ne peuvent pas être modifiés par des appels F_SETFL (ou demandés par F_GETFL) de fcntl(2).
7. f_mode : une combinaison des drapeaux de l'espace utilisateur et du mode, calculée par dentry_open(). Le but de cette manipulation est de stocker les accès en lecture et en écriture dans des bits séparés qu'on puisse tester facilement comme dans (f_mode & FMODE_WRITE) et (f_mode & FMODE_READ).
8. f_pos : la position courante dans le fichier pour la prochaine lecture ou écriture dans le fichier. Sous i386 c'est de type long long, i.e. une variable 64bit.
9. f_reada, f_ramax, f_raend, f_ralen, f_rawin : pour supporter la lecture anticipée (readahead) - trop complexe pour être discuté par des mortels ;)
10. f_owner : propriétaire des entrées/sorties sur le fichier qui recevra les notifications d'entrées/sorties asynchrones via le mécanisme SIGIO (voir fs/fcntl.c:kill_fasync()).
11. f_uid, f_gid - reçoit l'id (identificateur) de l'utilisateur et du groupe du processus qui a ouvert le fichier au moment où la structure de fichier a été créée dans get_empty_filp(). Si le fichier est une socket, c'est utilisé par netfilter ipv4.
12. f_error : utilisé par le client NFS pour retourner les erreurs d'écritures. C'est fixé dans fs/nfs/file.c et vérifié dans mm/filemap.c:generic_file_write().
13. f_version - mécanisme de gestion de version pour l'invalidation des caches, incrémentée (en utilisant la variable globale event) à  chaque changement de f_pos.
14. private_data : données privées du fichier qui peuvent être utilisées par le système de fichiers (i.e. coda y stocke les données d'identification) ou par les pilotes de périphériques. Les pilotes de périphériques (en présence de devfs) peuvent utiliser ce champ pour différencier plusieurs instances au lieu d'utiliser le classique nombre mineur encodé dans file-$gt;f_dentry-$gt;d_inode-$gt;i_rdev.

struct file_operations {
  struct module *owner;
  loff_t (*llseek) (struct file *, loff_t, int);
  ssize_t (*read) (struct file *, char *, size_t, loff_t *);
  ssize_t (*write) (struct file *, const char *, size_t, loff_t *);
  int (*readdir) (struct file *, void *, filldir_t);
  unsigned int (*poll) (struct file *, struct poll_table_struct *);
  int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
  int (*mmap) (struct file *, struct vm_area_struct *);
  int (*open) (struct inode *, struct file *);
  int (*flush) (struct file *);
  int (*release) (struct inode *, struct file *);
  int (*fsync) (struct file *, struct dentry *, int datasync);
  int (*fasync) (int, struct file *, int);
  int (*lock) (struct file *, int, struct file_lock *);
  ssize_t (*readv) (struct file *, const struct iovec *,
                    unsigned long, loff_t *);
  ssize_t (*writev) (struct file *, const struct iovec *,
                     unsigned long, loff_t *);
};

1. owner : un pointeur sur le module qui possède le sous-système en question. Seuls les pilotes ont besoin de le fixer à THIS_MODULE, heureusement les systèmes de fichiers peuvent l'ignorer car leurs compteurs de modules sont contrôlés au moment de mount/umount alors que les pilotes ont besoin de les contrôler au moment des open/release.
2. llseek : implémente l'appel système lseek(2). Il est habituellement omis et fs/read_write.c:default_llseek() est utilisé, qui fait ce qu'il faut (À FAIRE : forcer tous ceux qui le positionnent à NULL actuellement à  utiliser default_llseek - de cette façon nous économisons un if() dans llseek())
3. read : implémente l'appel système read(2). Les systèmes de fichiers peuvent utiliser mm/filemap.c:generic_file_read() pour les fichiers réguliers et fs/read_write.c:generic_read_dir() (qui renvoie simplement -EISDIR) pour les répertoires.
4. write : implémente l'appel système write(2). Les systèmes de fichiers peuvent utiliser mm/filemap.c:generic_file_write() pour les fichiers réguliers et l'ignorer pour les répertoires.
5. readdir : utilisé par le système de fichiers. Ignoré pour les fichiers réguliers, il implémente les appels système readdir(2) et getdents(2) pour les répertoires.
6. poll : implémente les appels système poll(2) et select(2).
7. ioctl : implémente les contrôles d'entrée/sortie des pilotes ou des systèmes de fichiers spécifiques. Remarquez que les ioctls comme FIBMAP, FIGETBSZ, FIONREAD sur les fichiers génériques sont implémentés aux niveaux supérieurs donc ils ne lisent jamais la méthode f_op-$gt;ioctl().
8. mmap : implémente l'appel système mmap(2). Les systèmes de fichiers peuvent utiliser generic_file_mmap ici pour les fichiers réguliers et l'ignorer pour les répertoires.
9. open : appelé au moment de open(2) par dentry_open(). Les systèmes de fichiers l'utilisent rarement, par exemple coda essaie de cacher localement le fichier au moment de l'ouverture.
10. flush : appelé à  chaque close(2) de ce fichier, pas nécessairement le dernier (voir la méthode release() plus bas). Le seul système de fichier qui l'utilise est le client NFS, pour vider toutes les pages modifiées. Remarquez qu'il peut retourner une erreur qui sera repassée dans l'espace utilisateur qui a fait l'appel système close(2).
11. release : appelé au dernier close(2) sur ce fichier, i.e. quand file-$gt;f_count atteint 0. Quoiqu'il soit défini comme retournant un entier, la valeur de retour est ignorée par le VFS (voir fs/file_table.c:__fput()).
12. fsync : correspond directement aux appels systèmes fsync(2)/fdatasync(2), le dernier argument spécifiant si c'est fsync ou fdatasync. Aucun travail pratiquement n'est fait par le VFS à  ce niveau, sauf faire correspondre le descripteur fichier à  une structure de fichier (file = fget(fd)) et monter/descendre le sémaphore inode-$gt;i_sem. Le système de fichiers ext2 ignore actuellement le dernier argument et fait exactement la même chose pour fsync(2) que pour fdatasync(2).
13. fasync : cette méthode est appelée quand file-$gt;f_flags & FASYNC change.
14. lock : la portion spécifique au système de fichier du mécanisme POSIX fcntl(2) de verrouillage de région de fichier. Le seul bug ici est qu'il est appelé après la partie dépendant du système de fichiers (posix_lock_file()), et que s'il réussit alors que le verrou POSIX standard a échoué, il ne sera jamais déverrouillé au niveau dépendant du système de fichiers.
15. readv : implémente l'appel système readv(2).
16. writev : implémente l'appel système writev(2).

IV-E. Super-bloc et gestion des points de montage

struct super_block {
    struct list_head        s_list;      /* À laisser au début */
    kdev_t                  s_dev;
    unsigned long           s_blocksize;
    unsigned char           s_blocksize_bits;
    unsigned char           s_lock;
    unsigned char           s_dirt;
    struct file_system_type *s_type;
    struct super_operations *s_op;
    struct dquot_operations *dq_op;
    unsigned long           s_flags;
    unsigned long           s_magic;
    struct dentry           *s_root;
    wait_queue_head_t       s_wait;
    struct list_head        s_dirty;     /* inodes modifiés */
    struct list_head        s_files;

    struct block_device     *s_bdev;
    struct list_head        s_mounts;    /* vfsmount(s) de celui-ci */
    struct quota_mount_options s_dquot;  /* options spécifiques aux quotas */

    union {
            struct minix_sb_info    minix_sb;
            struct ext2_sb_info     ext2_sb;
            ... all filesystems that need sb-private info ...
            void                    *generic_sbp;
    } u;
   /*
    * Le champ suivant n'est *que* pour VFS. Aucun système de fichiers 
    * n'a affaire à  lui, même pour jeter un oeil. Vous aurez été 
    * prévenus.
    */
    struct semaphore s_vfs_rename_sem;    /* Usine à  gaz */

   /* Le champ suivant est utilisé par knfsd pour convertir un handle de  
    * fichier (basé sur le numéro d'inode) en un dentry. Lorsqu'il dessine  
    * un chemin dans l'arbre du dcache à  partir du bas, il peut y avoir 
    * provisoirement un sous-chemin de dentrys qui n'est pas connecté à  
    * l'arbre principal. Ce sémaphore assure qu'il n'y ait jamais qu'un seul
    * chemin libéré ainsi par système de fichiers. Noter qu'avoir des 
    * fichiers (ou n'importe quoi d'autre, en dehors d'un répertoire) 
    * non connectés est autorisé, mais pas d'avoir des répertoires non 
    * connectés_
    */
    struct semaphore s_nfsd_free_path_sem;
};

1. s_list : une liste doublement chaînée de tous les super-blocs actifs ; remarquez que je ne dis pas « de tous les systèmes de fichiers montés » car sous Linux on peut avoir plusieurs instances d'un système de fichiers montées correspondant à  un seul super-bloc.
2. s_dev : pour les systèmes de fichiers qui requièrent qu'un bloc soit monté, i.e. pour les systèmes de fichiers FS_REQUIRES_DEV, c'est le i_dev du périphérique bloc. Pour les autres (appelés systèmes de fichiers anonymes) c'est un entier MKDEV(UNNAMED_MAJOR, i) où i est le premier bit non positionné dans le tableau unnamed_dev_in_use, de 1 à  255 inclus. Voir fs/super.c:get_unnamed_dev()/put_unnamed_dev(). Il a été suggéré plusieurs fois que les systèmes de fichiers anonymes n'utilisent pas le champ s_dev.
3. s_blocksize, s_blocksize_bits : taille de bloc (blocksize) et log2(blocksize).
4. s_lock : indique si le super-bloc est actuellement verrouillé par lock_super()/unlock_super().
5. s_dirt : mis quand le super-bloc est modifié, et enlevé à chaque fois qu'il est copié sur le disque.
6. s_type : pointeur sur struct file_system_type du système de fichiers correspondant. La méthode read_super() du système de fichiers n'a pas besoin de le positionner puisque le VFS fs/super.c:read_super() le fait pour vous si read_super() spécifique au système de fichiers réussit et le réinitialise à  NULL si elle échoue.
7. s_op : pointeur sur la structure super_operations qui contient les méthodes spécifiques au fs pour lire/écrire les inodes, et cætera. Il revient à la méthode read_super() du système de fichiers d'initialiser correctement s_op.
8. dq_op : les opérations de quota disque.
9. s_flags : les drapeaux du super-bloc.
10. s_magic : le nombre magique du système de fichiers. Utilisé par les systèmes de fichiers minix pour en différencier les multiples versions.
11. s_root : dentry de la racine du système de fichier. Il revient à  read_super() de lire l'inode racine sur le disque et de le passer à d_alloc_root() pour allouer le dentry et l'instancier. Certains systèmes de fichiers écrivent « root » (racine) autrement que « / » et utilisent alors la fonction plus générique d_alloc() pour attacher le dentry à  un nom, par exemple pipefs se monte lui-même sur « pipe: » comme sa propre racine au lieu de « / ».
12. s_wait : file d'attente des processus attendant que le super-bloc soit déverrouillé.
13. s_dirty : une liste de tous les inodes modifiés (dirty). Rappelez vous que si un inode est modifié (inode-$gt;i_state & I_DIRTY), il est dans la liste des inodes modifiés spécifique au super-bloc lié via inode-$gt;i_list.
14. s_files : une liste de tous les fichiers ouverts sur ce super-bloc. Utile pour décider si un système de fichiers peut être remonté en lecture seule, voir fs/file_table.c:fs_may_remount_ro() qui explore la liste sb-$gt;s_files et refuse le remontage s'il y a des fichiers ouverts en écriture (file-$gt;f_mode & FMODE_WRITE) ou des fichiers avec un effacement (unlink) suspendu (inode-$gt;i_nlink == 0).
15. s_bdev : pour FS_REQUIRES_DEV, il pointe sur une structure de périphérique bloc décrivant le périphérique sur lequel le système de fichiers est monté.
16. s_mounts : une liste de toutes les structures vfsmount, une pour chaque instance montée de ce super-bloc.
17. s_dquot : encore pour les quotas disque.

struct super_operations {
        void (*read_inode) (struct inode *);
        void (*write_inode) (struct inode *, int);

        void (*put_inode) (struct inode *);
        void (*delete_inode) (struct inode *);
        void (*put_super) (struct super_block *);
        void (*write_super) (struct super_block *);
        int (*statfs) (struct super_block *, struct statfs *);
        int (*remount_fs) (struct super_block *, int *, char *);
        void (*clear_inode) (struct inode *);
        void (*umount_begin) (struct super_block *);
};

1. read_inode : lit l'inode sur le système de fichiers. Est appelée seulement depuis fs/inode.c:get_new_inode() depuis iget4() (et donc iget()). Si un système de fichiers veut utiliser iget(), alors read_inode() doit être implémentée - autrement get_new_inode() va paniquer. Pendant que l'inode est lu, il est verrouillé (inode-$gt;i_state = I_LOCK). Quand la fonction retourne, tous les processus en attente de inode-$gt;i_wait sont réveillés. Le rôle de la méthode read_inode() du système de fichier est de localiser le bloc du disque qui contient l'inode à  lire, elle utilise la fonction du cache tampon bread() pour le lire et initialiser les différents champs de la structure de l'inode, par exemple les inode-$gt;i_op et inode-$gt;i_fop pour qu'au niveau du VFS on sache quelles opérations peuvent être effectuées sur l'inode ou le fichier correspondant. Les systèmes de fichiers qui n'implémentent pas read_inode() sont ramfs et pipefs. Par exemple, ramfs a sa propre fonction ramfs_get_inode() de génération d'inodes et toutes les opérations sur les inodes l'appellent quand il faut.
2. write_inode : écrit l'inode sur le disque. Similaire à  read_inode() dans ce qu'elle a besoin de localiser le bloc disque pertinent et d'interagir avec le cache tampon en appelant mark_buffer_dirty(bh). Cette méthode est appelée sur les inodes modifiés (ceux marqués modifiés avec mark_inode_dirty()) quand les inodes ont besoin d'être synchronisés individuellement ou lors de la synchronisation du système de fichiers complet.
3. put_inode : appelée à  chaque fois que le compteur de références est décrémenté.
4. delete_inode : appelé dès qu'à  la fois inode-$gt;i_count et inode-$gt;i_nlink atteignent 0. Le système de fichiers efface la copie sur le disque de l'inode et appelle clear_inode() sur l'inode du VFS pour « l'exécuter sans autre forme de procès ».
5. put_super : appelé dans les dernières étapes de l'appel système umount(2) pour notifier au système de fichiers que toutes les variables privées qu'il détient concernant cette instance doivent être libérées. Typiquement il voudra brelse() le verrou contenant le super-bloc et kfree() tous les bitmaps alloués pour les blocs libres, inodes, et cætera.
6. write_super : appelé quand il faut écrire le super-bloc sur le disque. Il devra trouver le bloc contenant le super-bloc (habituellement conservé dans la zone sb-private) et mark_buffer_dirty(bh) . Il doit aussi nettoyer le drapeau sb-$gt;s_dirt.
7. statfs : implémente les appels systèmes fstatfs(2)/statfs(2). Remarquez que le pointeur sur struct statfs passé en argument est un pointeur noyau, pas un pointeur utilisateur donc nous n'avons besoin de faire aucune entrée/sortie depuis/vers l'espace utilisateur. Si statfs(2) n'est pas implémentée alors elle échouera avec ENOSYS.
8. remount_fs : appelé à  chaque fois qu'il faut remonter le système de fichiers.
9. clear_inode : appelée depuis clear_inode() au niveau VFS. Les systèmes de fichiers qui attachent des données privées à  la structure d'inode (via le champ generic_ip) doivent les libérer ici.
10. umount_begin : appelé durant un démontage forcé pour que le système de fichiers soit prévenu d'avance et fasse de son mieux pour éviter de rester occupé. Utilisé uniquement par NFS actuellement. Ceci n'a rien à  voir avec l'idée d'un support générique du démontage forcé au niveau VFS.

1. Le pilote du système de fichiers est chargé si besoin est et le compteur de références du module est incrémenté. Remarquez que pendant l'opération de montage, le compteur de références du module du système de fichiers est incrémenté deux fois - une fois par do_mount() lors de l'appel à  get_fs_type() et une fois par get_sb_dev() lors de l'appel à  get_filesystem() si read_super() a réussi. Le premier incrément est là  pour éviter que le module soit déchargé pendant que nous sommes dans la méthode read_super() et le second pour indiquer que le module est utilisé par l'instance montée considérée. Évidemment, do_mount() décrémente le compteur avant de retourner, donc finalement le compteur n'augmente que de 1 après chaque montage.
2. Puisque dans notre cas fs_type-$gt;fs_flags & FS_REQUIRES_DEV est vrai, le super-bloc est initialisé par un appel à  get_sb_bdev() qui obtient la référence des périphériques de bloc et interagit avec la méthode read_super() du système de fichiers pour remplir le super-bloc. Si tout se passe bien, la structure super_block est initialisée et nous avons une référence de plus au module du système de fichiers et une référence au périphérique de bloc sous-jacent.
3. Une nouvelle structure vfsmount est allouée et liée à  la liste sb-$gt;s_mounts et à  la liste globale vfsmntlist. Le champ mnt_instances de vfsmount permet de trouver toutes les instances montées sur notre super-bloc. Le champ mnt_list permet de trouver toutes les instances pour tous les super-blocs du système. Le champ mnt_sb pointe sur le super-bloc et mnt_root obtient une nouvelle référence sur le dentry sb-$gt;s_root.

IV-F. Exemple de système de fichiers virtuel : pipefs

static DECLARE_FSTYPE(pipe_fs_type, "pipefs", pipefs_read_super,
        FS_NOMOUNT|FS_SINGLE);

static int __init init_pipe_fs(void)
{
        int err = register_filesystem(&pipe_fs_type);
        if (!err) {
                pipe_mnt = kern_mount(&pipe_fs_type);
                err = PTR_ERR(pipe_mnt);
                if (!IS_ERR(pipe_mnt))
                        err = 0;
        }
        return err;
}

static void __exit exit_pipe_fs(void)
{
        unregister_filesystem(&pipe_fs_type);
        kern_umount(pipe_mnt);
}

module_init(init_pipe_fs)
module_exit(exit_pipe_fs)

1. Un nouveau numéro de périphérique non nommé (anonyme) est alloué en positionnant un bit dans le bitmap unnamed_dev_in_use; s'il n'y a plus de bit disponible, alors kern_mount() échoue avec EMFILE.
2. Une nouvelle structure de super-bloc est allouée par le biais de get_empty_super(). La fonction get_empty_super() parcourt la liste des super-blocs ancrée sur super_block et cherche une entrée vide, i.e. s-$gt;s_dev == 0. Si on ne trouve pas de super-bloc vide, on en alloue un nouveau en utilisant kmalloc() à  la priorité GFP_USER. Le nombre maximum de super-blocs dans tout le système est vérifié dans get_empty_super(), donc s'il commence à  y avoir des échecs, on peut ajuster le réglage /proc/sys/fs/super-max.
3. Une méthode spécifique au système de fichiers pipe_fs_type-$gt;read_super(), i.e. pipefs_read_super(), est invoquée qui alloue l'inode racine et le dentry racine sb-$gt;s_root, et affecte la valeur &pipefs_ops à  sb-$gt;s_op.
4. Alors kern_mount() appelle add_vfsmnt(NULL, sb-$gt;s_root, "none"), qui alloue une nouvelle structure vfsmount et la lie à  vfsmntlist et sb-$gt;s_mounts.
5. Cette nouvelle structure vfsmount est affectée à  pipe_fs_type-$gt;kern_mnt qui est retourné. La raison pour laquelle la valeur retournée par kern_mount() est une structure vfsmount est que même les systèmes de fichiers FS_SINGLE peuvent être montés plusieurs fois et qu'alors leurs mnt-$gt;mnt_sb pointeraient sur la même variable qu'il serait idiot de retourner à  chaque appel à  kern_mount().

IV-G. Exemple de système de fichiers sur disque : BFS

static DECLARE_FSTYPE_DEV(bfs_fs_type, "bfs", bfs_read_super);

static int __init init_bfs_fs(void)
{
        return register_filesystem(&bfs_fs_type);
}

static void __exit exit_bfs_fs(void)
{
        unregister_filesystem(&bfs_fs_type);
}

module_init(init_bfs_fs)
module_exit(exit_bfs_fs)

1. set_blocksize(s-$gt;s_dev, BFS_BSIZE) : comme nous sommes sur le point d'interagir avec le périphérique bloc via le cache tampon, on doit initialiser quelques trucs, à  savoir fixer la taille de bloc et aussi informer le VFS via les champs s-$gt;s_blocksize et s-$gt;s_blocksize_bits.
2. bh = bread(dev, 0, BFS_BSIZE) : on lit le bloc 0 du périphérique passé via s-$gt;s_dev. Ce bloc est le super-bloc du système de fichiers.
3. Le super-bloc est validé par son nombre BFS_MAGIC, et, s'il est valide, est stocké dans le champ sb-private s-$gt;su_sbh (qui est en réalité s-$gt;u.bfs_sb.si_sbh).
4. Alors on alloue le bitmap d'inodes en utilisant kmalloc(GFP_KERNEL) et on remet tous les bits à  0 sauf les deux premiers que l'on met à  1 pour indiquer qu'il ne faut jamais allouer les inodes 0 et 1. Le 2 est l'inode racine et le bit correspondant sera mis à 1 quelques lignes plus tard de toutes façons - le système de fichiers doit avoir un inode racine valide au moment du montage !
5. Puis on initialise s-$gt;s_op, donc on pourra maintenant invoquer le cache inode via iget(), ce qui revient à  invoquer s_op-$gt;read_inode(). On trouve le bloc contenant l'inode spécifié (par inode-$gt;i_ino et inode-$gt;i_dev) et on le lit. Si on n'arrive pas à  avoir l'inode racine, on libère le bitmap d'inodes ainsi que le tampon du super-bloc dans le tampon de cache et on renvoie NULL. Si l'inode racine était OK en lecture, on alloue un dentry de nom "/" (puisqu'il devient racine) et on l'instancie avec cet inode.
6. Maintenant on parcourt tous les inodes du système de fichiers et on les lit dans le but de positionner les bits correspondants dans notre bitmap d'inodes interne et aussi de calculer d'autres paramètres internes comme le décalage du dernier inode et les blocs de début/fin du dernier fichier. Chaque inode qu'on lit est renvoyé dans le cache inode via iput() - on ne conserve pas de référence sur lui plus longtemps que nécessaire.
7. Si le système de fichiers n'a pas été monté en lecture seule (read_only), on marque le tampon du super-bloc modifié (dirty) et on met le drapeau s-$gt;s_dirt (À FAIRE : Pourquoi faire ça ? A l'origine, je l'ai fait parce que minix_read_super() le fait mais ni minix ni BFS ne semblent modifier le super-bloc dans read_super()).
8. Tout est bon, donc on retourne le super-bloc initialisé à  l'appelant au niveau du VFS, i.e. fs/super.c:read_super().

1. Les noms de l'espace utilisateurs sont copiés dans l'espace noyau par le biais de la fonction getname() qui effectue les vérifications d'erreurs.
2. Ces noms sont convertis au format nameidata en utilisant l'interaction path_init()/path_walk() avec le dcache. Le résultat est stocké dans les structures old_nd et nd.
3. Si old_nd.mnt != nd.mnt alors le lien inter-périphériques (cross-device link) EXDEV est retourné - on ne peut pas lier entre systèmes de fichiers, ce qui sous Linux se traduit par - on ne peut pas lier entre les instances montées d'un système de fichiers (ou, en particulier entre systèmes de fichiers).
4. Un nouveau dentry correspondant à  nd est créé par lookup_create() .
5. Une fonction générique vfs_link() est appelée qui vérifie si on peut créer une nouvelle entrée dans le répertoire puis invoque la méthode dir-$gt;i_op-$gt;link() qui nous ramène à  la fonction fs/bfs/dir.c:bfs_link() spécifique au système de fichiers.
6. Dans bfs_link(), on teste si c'est un répertoire qu'on essaye de lier et si oui, on refuse avec l'erreur EPERM. C'est le même comportement que le standard (ext2).
7. On essaie d'ajouter la nouvelle entrée de répertoire au répertoire spécifié en appelant la fonction bfs_add_entry() qui parcourt toutes les entrées en cherchant une place inutilisée (de-$gt;ino == 0) et, quand elle en trouve une, écrit la paire nom/inode dans le bloc correspondant et le marque modifié (avec une priorité non-super-bloc).
8. Si on a réussi à  ajouter l'entrée de répertoire, il n'y plus de risque que l'opération échoue donc on incrémente inode-$gt;i_nlink, met à  jour inode-$gt;i_ctime et marque l'inode modifiée tout en créant la nouvelle instance de dentry avec l'inode.

IV-H. Domaines d'exécution et formats binaires

1. les trois octets hauts - émulation de bug : STICKY_TIMEOUTS, WHOLE_SECONDS, et cætera.
2. l'octet du bas - personnalité propre, un nombre unique.

• int register_exec_domain(struct exec_domain *) : enregistre le domaine d'exécution en le liant à  la liste chaînée simple exec_domains sous la protection en écriture du verrou tournant exec_domains_lock. Renvoie 0 pour un succès, différent de zéro pour un échec.
• int unregister_exec_domain(struct exec_domain *) : dés-enregistre le domaine d'exécution en le déliant de la liste exec_domains, en utilisant encore le verrou tournant exec_domains_lock en mode écriture. Renvoie 0 en cas de succès.

static void UW7_lcall7(int segment, struct pt_regs * regs)
{
       abi_dispatch(regs, &uw7_funcs[regs-$gt;eax & 0xff], 1);
}

V. Le cache de pages Linux

	struct address_space {
		struct list_head        clean_pages;
		struct list_head        dirty_pages;
		struct list_head        locked_pages;
		unsigned long           nrpages;
		struct address_space_operations *a_ops;
		struct inode            *host;
		struct vm_area_struct	*i_mmap;
		struct vm_area_struct	*i_mmap_shared;
		spinlock_t		i_shared_lock;
 
	};

	struct address_space_operations {
		int (*writepage)(struct page *);
		int (*readpage)(struct file *, struct page *);
		int (*sync_page)(struct page *);
		int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
		int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
		int (*bmap)(struct address_space *, long);
	};

VI. Mécanismes de communication inter-processus (IPC)

VI-A. Sémaphores

VI-A-1. Interfaces d'appels système des sémaphores

VI-A-1-a. sys_semget()

VI-A-1-b. sys_semctl()

VI-A-1-c. sys_semop()

VI-A-1-c-i. Opérations de sémaphores non-bloquantes

VI-A-1-c-ii. Opérations de sémaphores qui échouent

VI-A-1-c-iii. Opérations de sémaphore bloquantes

• Si le sémaphore a été retiré, l'appel système échoue avec EIDRM.
• Si l'élément status de la structure struct sem_queue a été mis à  1, c'est que la tâche a été réveillée pour réessayer l'exécution des opérations du sémaphore. Un autre appel à  try_atomic_semop est fait pour exécuter la séquence d'opérations du sémaphore. Si try_atomic_sweep() renvoie 1, alors la tâche doit encore bloquer comme décrit ci-dessus. Sinon, 0 est retourné en cas de succès, ou le code d'erreur approprié en cas d'échec. Avant que sys_semop() retourne, current-$gt;semsleeping est nettoyé, et struct sem_queue est retiré de la file. Si une des opérations de sémaphore était alors en train d'altérer le sémaphore (augmentation ou diminution), update_queue est appelé pour parcourir la file des opérations de sémaphore suspendues pour l'ensemble de sémaphores et toutes les tâches endormies qui ne doivent plus bloquer sont réveillées.
• Si l'élément status de la structure struct sem_queue n'est PAS mis à 1, et que l'élément struct sem_queue n'a pas été enlevé de la file, c'est que la tâche a été réveillée par une interruption. Dans ce cas, l'appel système échoue avec EINTR. Avant de retourner, current-$gt;semsleeping est nettoyé, et struct sem_queue est retiré de la file. De plus, update_queue est appelé si l'une des opérations a altéré des opérations.
• Si l'élément status de la structure struct sem_queue n'est PAS mis à  1, et que l'élément struct sem_queue n'a pas été retiré de la file, alors les opérations du sémaphore ont déjà  été exécutées par update_queue. Le status de la file, nul en cas de succès ou négatif en cas d'échec, devient la valeur de retour de l'appel système.

VI-A-2. Structures spécifiques au support des sémaphores

VI-A-2-a. struct sem_array

/* Une structure de données sem_array pour chaque ensemble de sémaphores 
   du système. */ 
struct sem_array {
    struct kern_ipc_perm sem_perm; /* permissions - voir ipc.h */
    time_t sem_otime; /* instant du dernier semop */
    time_t sem_ctime; /* instant du dernier changement */
    struct sem *sem_base; /* pointe sur le premier sémaphore du tableau */
    struct sem_queue *sem_pending; /* opérations suspendues à  exécuter */
    struct sem_queue **sem_pending_last; /* dernière operation suspendue */
    struct sem_undo *undo; /* les undos demandés pour ce tableau * /
    unsigned long sem_nsems; /* aucun sémaphore dans le tableau */
};

VI-A-2-b. struct sem

/* Une structure de sémaphore pour chaque sémaphore du système. */
struct sem {
    int     semval;     /* valeur courante */
    int     sempid;     /* pid de la dernière opération */
};

VI-A-2-c. struct seminfo

struct  seminfo {
    int semmap;
    int semmni;
    int semmns;
    int semmnu;
    int semmsl;
    int semopm;
    int semume;
    int semusz;
    int semvmx;
    int semaem;
};

VI-A-2-d. struct semid64_ds

struct semid64_ds {
    struct ipc64_perm sem_perm;  /* permissions - voir ipc.h */
    __kernel_time_t sem_otime;   /* instant du dernier semop */
    unsigned long   __unused1;
    __kernel_time_t sem_ctime;   /* instant de la dernière modification */
    unsigned long   __unused2;
    unsigned long   sem_nsems;   /* aucun sémaphore dans le tableau */
    unsigned long   __unused3;
    unsigned long   __unused4;
};

VI-A-2-e. struct sem_queue

/* Une . */
struct sem_queue {
  struct sem_queue *  next;    /* entrée suivante dans la file */
  struct sem_queue ** prev;    /* entrée précédente dans la file, */
                               /* *(q-$gt;prev) == q */
  struct task_struct* sleeper; /* ce processus */
  struct sem_undo *   undo;    /* structure d'undo  */
  int                 pid;     /* identificateur du processus demandeur */
  int                 status;  /* statut d'exécution de l'opération */
  struct sem_array *  sma;     /* tableau de sémaphores pour les operations */
  int                 id;      /* identificateur interne du sémaphore */
  struct sembuf *     sops;    /* tableau des opérations suspendues */
  int                 nsops;   /* nombre d'opérations */
  int                 alter;   /* l'opération va modifier le sémaphore */
};

VI-A-2-f. struct sembuf

/* les appels systèmes semop prennent un tableau de ceux-ci. */
struct sembuf {
    unsigned short  sem_num;        /* index du sémaphore dans le tableau */
    short           sem_op;         /* operation sur le sémaphore */
    short           sem_flg;        /* options */
};

VI-A-2-g. struct sem_undo

/* Chaque tâche a sa liste d'opérations à  annuler. Les annulations sont 
 * faites automatiquement quand le processus se termine.
 */
struct sem_undo {
  struct sem_undo *  proc_next;  /* entrée suivante pour ce processus */
  struct sem_undo *  id_next;    /* entrée suivante pour cet ensemble */
                                 /* de sémaphores */
  int                semid;      /* identificateur de l'ensemble de sémaphores */
  short *            semadj;     /* tableau d'adaptations, une par sémaphore */
};

VI-A-3. Les fonctions du support des sémaphores

VI-A-3-a. newary()

• L'élément sem_base pour l'ensemble est initialisé à  l'adresse suivant immédiatement la portion (struct sem_array) des données nouvellement allouées, ce qui correspond au premier sémaphore de l'ensemble.
• La file sem_pending est initialisée et laissée vide .

VI-A-3-b. freeary()

• La fonction ipc_rmid est appelée (par l'intermédiaire de l'enveloppe sem_rmid()) pour effacer l'identificateur de l'ensemble de sémaphores et pour récupérer un pointeur sur l'ensemble de sémaphores.
• La liste d'opérations à  annuler de l'ensemble de sémaphores est invalidée.
• Tous les processus suspendus sont réveillés et amenés à échouer avec EIDRM.
• Le nombre de sémaphores utilisés est diminué du nombre de sémaphores de l'ensemble retiré.
• La mémoire associée à  l'ensemble de sémaphores est libérée.

VI-A-3-c. semctl_down()

VI-A-3-c-i. IPC_RMID

VI-A-3-c-ii. IPC_SET

VI-A-3-d. semctl_nolock()

VI-A-3-d-i. IPC_INFO et SEM_INFO

VI-A-3-d-ii. SEM_STAT

VI-A-3-e. semctl_main()

VI-A-3-e-i. GETALL

VI-A-3-e-ii. SETALL

• Les valeurs des sémaphores sont copiées dans l'ensemble de sémaphores.
• Les ajustements des sémaphores de la file d'annulation relative à l'ensemble de sémaphores sont nettoyés.
• La valeur sem_ctime pour l'ensemble de sémaphores est fixée.
• La fonction update_queue est appelée pour parcourir la file des semops suspendues et pour rechercher toutes les tâches qui peuvent être terminées par l'opération SETALL. Toutes les tâches suspendues qui ne sont plus bloquées sont réveillées.

VI-A-3-e-iii. IPC_STAT

VI-A-3-e-iv. GETVAL

VI-A-3-e-v. GETPID

VI-A-3-e-vi. GETNCNT

VI-A-3-e-vii. GETZCNT

VI-A-3-e-viii. SETVAL

• Les ajustements de ce sémaphore sont recherchés dans la file d'annulation . Les ajustements trouvés sont remis à  zéro.
• La valeur du sémaphore est fixée à  la valeur donnée.
• La valeur sem_ctime est mise à  jour.
• La fonction update_queue est appelée pour parcourir la file des semops suspendues et pour chercher les tâches qui peuvent se terminer par l'opération SETALL. Toutes les tâches qui ne sont plus bloquées sont réveillées.

VI-A-3-f. count_semncnt()

VI-A-3-g. count_semzcnt()

VI-A-3-h. update_queue()

VI-A-3-i. try_atomic_semop()

VI-A-3-j. sem_revalidate()

VI-A-3-k. freeundos()

VI-A-3-l. alloc_undo()

VI-A-3-m. sem_exit()

• La structure d'annulation et l'identificateur de l'ensemble de sémaphores sont validés.
• La liste d'annulations de l'ensemble de sémaphores correspondant est parcourue pour trouver une référence à  cette structure d'annulation et pour la retirer de la liste.
• Les modifications indiquées dans la structure d'annulation sont effectuées sur l'ensemble de sémaphores.
• Le paramètre sem_otime de l'ensemble de sémaphores est mis à  jour.
• update_queue est appelée pour parcourir la file des semops suspendues et pour réveiller toutes les tâches qui n'ont plus à  être bloquées par l'exécution des opérations d'annulation.
• La structure d'annulation est libérée.

VI-B. Les files de messages

VI-B-1. L'interface d'appel système des messages

VI-B-1-a. sys_msgget()

VI-B-1-b. sys_msgctl()

VI-B-1-b-i. IPC_INFO ( or MSG_INFO)

VI-B-1-b-ii. IPC_STAT ( or MSG_STAT)

VI-B-1-b-iii. IPC_SET

VI-B-1-b-iv. IPC_RMID

VI-B-1-c. sys_msgsnd()

1. Elle valide l'adresse du tampon et le type de message, puis invoque load_msg pour charger le contenu du message utilisateur dans un objet temporaire msg de type struct msg_msg. Les champs type de message et taille de message de msg sont aussi initialisés.
2. Elle verrouille le verrou tournant global de file de messages et obtient le descripteur de file de messages associé à l'identificateur de la file de messages. Si une telle file de messages n'existe pas, retourne EINVAL.
3. Invoque ipc_checkid (via msg_checkid()) pour vérifier que l'identificateur de file de messages est valide et appelle ipcperms pour vérifier les permissions du processus appelant.
4. Regarde la taille du message pour voir s'il reste assez de place dans la file d'attente pour le message. Si non, les actions suivantes sont exécutées : Si IPC_NOWAIT est spécifié dans msgflg, le verrou tournant global de file de messages est déverrouillé, les ressources mémoire pour ce message sont libérées, et EAGAIN est renvoyé. Elle invoque ss_add pour retirer la tâche courante de la file d'attente d'émission, déverrouille aussi le verrou tournant global de file de messages et invoque schedule() pour endormir la tâche courante. Une fois réveillée, obtient à  nouveau le verrou tournant global et vérifie que l'identificateur de la file de messages est toujours valide. S'il n'est plus valide, ERMID est renvoyé. Invoque ss_del pour retirer la tâche émettrice de la file d'attente d'émission. S'il y a un signal suspendu pour la tâche, sys_msgsnd() déverrouille le verrou tournant global, invoque free_msg pour libérer le tampon du message, et renvoie EINTR. Autrement, la fonction retourne en arrière pour vérifier encore s'il y a assez de place dans la file d'attente des messages.
5. Invoque pipelined_send pour essayer d'envoyer directement le message au récepteur en attente.
6. S'il n'y a pas de récepteur attendant ce message, met msg dans la file d'attente des messages (msq-$gt;q_messages). Met à  jour les champs q_cbytes et q_qnum pour le descripteur de file de messages, ainsi que les variables globales msg_bytes et msg_hdrs, qui indiquent le nombre total d'octets utilisés pour les messages et le nombre total de messages dans tout le système.
7. Si le message a été envoyé ou enlevé de la file avec succès, met à  jour les champs q_lspid et q_stime du descripteur de file de messages et relâche le verrou tournant global de file de messages.

VI-B-1-d. sys_msgrcv()

1. D'abord, elle invoque convert_mode pour déduire le mode de recherche de msgtyp. Ensuite sys_msgrcv() verrouille le verrou tournant global de file de messages et obtient le descripteur de file de messages associé à  l'identificateur de file de messages. Si celle file de messages n'existe pas, renvoie EINVAL.
2. Vérifie si la tâche courante a les permissions voulues pour accéder à  la file de messages.
3. d'attente en commençant par le premier pour vérifier si le type du message correspond au type demandé. sys_msgrcv() continue sa recherche jusqu'à  ce qu'elle trouve un message du type voulu ou jusqu'à  la fin de la liste. Si le mode de recherche est SEARCH_LESSEQUAL, c'est le premier message de la file dont le type est inférieur au égal à msgtyp qui est cherché.
4. Si le message est trouvé, sys_msgrcv() exécute les sous-étapes suivantes : Si la taille du message est plus grande que celle attendue et si msgflg indique qu'aucune erreur n'est autorisée, on déverrouille le verrou tournant global de file de messages et on renvoie E2BIG. On retire le message de la file d'attente et on met à jour les statistiques de la file de messages. On réveille toutes les tâches endormies dans la file d'attente d'émission. Après le retrait du message de la file à l'étape précédente, l'un des émetteurs peut continuer. On va à la dernière étape".
5. Si aucun message correspondant aux critères des récepteurs n'est trouvé dans la file d'attente de messages, msgflg est vérifié. Si IPC_NOWAIT est mis, le verrou tournant global de file de messages est levé et ENOMSG est retourné. Autrement, le récepteur est mis dans la file d'attente de réception comme suit : Une structure de données struct msg_receiver msr est allouée et est ajoutée en tête de la file d'attente. Le champ r_tsk de msr prend pour valeur la tâche courante. Les champs r_msgtype et r_mode sont initialisés avec respectivement le type de message et le mode voulus. Si msgflg indique MSG_NOERROR, alors le champ r_maxsize de msr prend pour valeur msgsz, autrement INT_MAX. Le champs r_msg est initialisé pour indiquer qu'aucun message n'a encore été reçu. Une fois l'initialisation terminée, l'état de la tâche réceptrice est mis à  TASK_INTERRUPTIBLE, le verrou tournant global de file de messages est enlevé, et schedule() est invoquée.
6. Une fois le récepteur réveillé, le champ r_msg de msr est vérifié. Ce champ est utilisé pour stocker le message envoyé à  travers le tube ou en cas d'erreur, pour stocker le statut d'erreur. Si le champ r_msg contient le message voulu, alors on va à la dernière étape". Sinon, le verrou tournant global de file de messages est une nouvelle fois posé.
7. Une fois le verrou tournant obtenu, le champ r_msg est re-vérifié pour voir si le message a été reçu pendant qu'on attendait le verrou. Si le message a été reçu, on va à la dernière étape".
8. Si le champ r_msg est resté inchangé, c'est que la tâche a été est réveillée pour une nouvelle tentative. Dans ce cas, msr est enlevé de la file. S'il y a un signal suspendu pour la tâche, on enlève le verrou tournant global de file de messages et on renvoie EINTR. Sinon, la fonction doit revenir en arrière et réessayer.
9. Si le champ r_msg montre qu'une erreur s'est produite pendant le sommeil, le verrou tournant global de file de messages est levé et l'erreur est renvoyée.
10. Après avoir vérifié l'adresse du tampon utilisateur msp, le type de message est chargé dans le champ mtype de msp, et store_msg est invoquée pour copier le contenu du message dans le champ mtext de msp. Finalement la mémoire occupée par ce message est libérée par la fonction free_msg.

VI-B-2. Structures spécifiques aux messages

VI-B-2-a. struct msg_queue

/* une structure msq_queue pour chaque file présente dans le système */
struct msg_queue {
        struct kern_ipc_perm q_perm;
        time_t q_stime;                 /* instant du dernier msgsnd */
        time_t q_rtime;                 /* instant du dernier msgrcv */
        time_t q_ctime;                 /* instant du dernier changement */
        unsigned long q_cbytes;         /* nb actuel d'octets dans la file */
        unsigned long q_qnum;           /* nb de messages dans la file */
        unsigned long q_qbytes;         /* nb maxi d'octets dans la file */
        pid_t q_lspid;                  /* pid du dernier msgsnd */
        pid_t q_lrpid;                  /* pid de la dernière réception */

        struct list_head q_messages;
        struct list_head q_receivers;
        struct list_head q_senders;
};

VI-B-2-b. struct msg_msg

/* une structure msg_msg pour chaque message */
struct msg_msg {
        struct list_head m_list;
        long  m_type;
        int m_ts;           /* taille du texte du message */
        struct msg_msgseg* next;
        /* le message proprement dit suit immédiatement */
};

VI-B-2-c. struct msg_msgseg

/* un segment de message pour chaque message */
struct msg_msgseg {
        struct msg_msgseg* next;
        /* la partie suivante du message suit immédiatement */
};

VI-B-2-d. struct msg_sender

/* un msg_sender pour chaque émetteur endormi */
struct msg_sender {
        struct list_head list;
        struct task_struct* tsk;
};

VI-B-2-e. struct msg_receiver

/* une structure msg_receiver pour chaque émetteur endormi */
struct msg_receiver {
        struct list_head r_list;
        struct task_struct* r_tsk;

        int r_mode;
        long r_msgtype;
        long r_maxsize;

        struct msg_msg* volatile r_msg;
};

VI-B-2-f. struct msqid64_ds

struct msqid64_ds {
        struct ipc64_perm msg_perm;
        __kernel_time_t msg_stime;      /* instant du dernier msgsnd */
        unsigned long   __unused1;
        __kernel_time_t msg_rtime;      /* instant du dernier msgrcv */
        unsigned long   __unused2;
        __kernel_time_t msg_ctime;      /* instant du dernier changement */
        unsigned long   __unused3;
        unsigned long  msg_cbytes;      /* nb actuel d'octets dans la file */
        unsigned long  msg_qnum;        /* nb de messages dans la file */
        unsigned long  msg_qbytes;      /* nb max d'octets dans la file */
        __kernel_pid_t msg_lspid;       /* pid du dernier msgsnd */
        __kernel_pid_t msg_lrpid;       /* pid de la dernière réception */
        unsigned long  __unused4;
        unsigned long  __unused5;
};

VI-B-2-g. struct msqid_ds

 struct msqid_ds {
        struct ipc_perm msg_perm;
        struct msg *msg_first;          /* premier message de la file, inutilisé  */
        struct msg *msg_last;           /* dernier message de la file, inutilisé */
        __kernel_time_t msg_stime;      /* instant du dernier msgsnd  */
        __kernel_time_t msg_rtime;      /* instant du dernier msgrcv */
        __kernel_time_t msg_ctime;      /* instant du dernier changement */
        unsigned long  msg_lcbytes;     /* recycler les champs pour 32 bits */
        unsigned long  msg_lqbytes;     /* idem */
        unsigned short msg_cbytes;      /* nb actuel d'octets dans la file */
        unsigned short msg_qnum;        /* nb de messages dans la file */
        unsigned short msg_qbytes;      /* nb max d'octets dans la file */
        __kernel_ipc_pid_t msg_lspid;   /* pid du dernier msgsnd */
        __kernel_ipc_pid_t msg_lrpid;   /* pid de la dernière réception */
};

VI-B-2-h. msg_setbuf

struct msq_setbuf {
        unsigned long   qbytes;
        uid_t           uid;
        gid_t           gid;
        mode_t          mode;
};

VI-B-3. Fonctions de support des messages

VI-B-3-a. newque()

• La structure struct kern_ipc_perm est initialisée.
• Les champs q_stime et q_rtime du descripteur de message sont initialisés à  0. Le champ q_ctime est mis à  CURRENT_TIME.
• Le nombre maximum d'octets alloués pour cette file de messages (q_qbytes) est mis à MSGMNB, et le nombre d'octets utilisés actuellement par la file (q_cbytes) est initialisé à  0.
• La file d'attente de messages (q_messages), la file d'attente de réception (q_receivers), la file d'attente d'émission (q_senders) sont initialisées vides toutes les trois.

VI-B-3-b. freeque()

VI-B-3-c. ss_wakeup()

VI-B-3-d. ss_add()

VI-B-3-e. ss_del()

VI-B-3-f. expunge_all()

VI-B-3-g. load_msg()

VI-B-3-h. store_msg()

VI-B-3-i. free_msg()

VI-B-3-j. convert_mode()

VI-B-3-k. testmsg()

• Le mode de recherche indique de rechercher tous les messages (SEARCH_ANY).
• Le mode de recherche est SEARCH_LESSEQUAL et le type de message est inférieur ou égal au type désiré.
• Le mode de recherche est SEARCH_EQUAL et le type de message est le même que celui demandé.
• Le mode de recherche est SEARCH_NOTEQUAL et le type de message n'est pas celui désiré.

VI-B-3-l. pipelined_send()

VI-B-3-m. copy_msqid_to_user()

VI-B-3-n. copy_msqid_from_user()

VI-C. La mémoire partagée

VI-C-1. Interfaces d'appels système de la mémoire partagée

VI-C-1-a. sys_shmget()

VI-C-1-b. sys_shmctl()

VI-C-1-b-i. IPC_INFO

VI-C-1-b-ii. SHM_INFO

VI-C-1-b-iii. SHM_STAT, IPC_STAT

VI-C-1-b-iv. SHM_LOCK, SHM_UNLOCK

VI-C-1-b-v. IPC_RMID

VI-C-1-b-vi. IPC_SET

VI-C-1-c. sys_shmat()

VI-C-1-d. sys_shmdt()

VI-C-2. Les structures de support de la mémoire partagée

VI-C-2-a. struct shminfo64

struct shminfo64 {
        unsigned long   shmmax;
        unsigned long   shmmin;
        unsigned long   shmmni;
        unsigned long   shmseg;
        unsigned long   shmall;
        unsigned long   __unused1;
        unsigned long   __unused2;
        unsigned long   __unused3;
        unsigned long   __unused4;
};

VI-C-2-b. struct shm_info

struct shm_info {
        int used_ids;
        unsigned long shm_tot;  /* shm total alloué */
        unsigned long shm_rss;  /* shm total résident */
        unsigned long shm_swp;  /* shm total copié en mémoire virtuelle (swap)*/
        unsigned long swap_attempts;
        unsigned long swap_successes;
};

VI-C-2-c. struct shmid_kernel

struct shmid_kernel /* données privées du noyau */
{
        struct kern_ipc_perm    shm_perm;
        struct file *           shm_file;
        int                     id;
        unsigned long           shm_nattch;
        unsigned long           shm_segsz;
        time_t                  shm_atim;
        time_t                  shm_dtim;
        time_t                  shm_ctim;
        pid_t                   shm_cprid;
        pid_t                   shm_lprid;
};

VI-C-2-d. struct shmid64_ds

struct shmid64_ds {
    struct ipc64_perm   shm_perm;       /* permissions pour les opérations */
    size_t              shm_segsz;      /* taille du segment (en octets) */
    __kernel_time_t     shm_atime;      /* instant du dernier attachement */
    unsigned long       __unused1;
    __kernel_time_t     shm_dtime;      /* instant du dernier détachement */
    unsigned long       __unused2;
    __kernel_time_t     shm_ctime;      /* instant du dernier chgt */
    unsigned long       __unused3;
    __kernel_pid_t      shm_cpid;       /* pid du créateur */
    __kernel_pid_t      shm_lpid;       /* pid de la dernière opération */
    unsigned long       shm_nattch;     /* nb d'attachements actuel */
    unsigned long       __unused4;
    unsigned long       __unused5;
};

VI-C-2-e. struct shmem_inode_info

struct shmem_inode_info {
    spinlock_t       lock;
    unsigned long    max_index;
    swp_entry_t      i_direct[SHMEM_NR_DIRECT]; /* pour les premiers blocs */
    swp_entry_t      **i_indirect;  /* double indirection pour les blocs */
    unsigned long    swapped;
    int              locked;        /* dans la mémoire */
    struct list_head list;
};

VI-C-3. Les fonctions du support de la mémoire partagée

VI-C-3-a. newseg()

VI-C-3-b. shm_get_stat()

VI-C-3-c. shmem_lock()

• find_lock_page() est appelée pour verrouiller la page (en positionnant PG_locked) et pour incrémenter le compteur de références de la page. L'incrémentation du compteur de références assure que le segment de mémoire partagée reste verrouillé tout au long de l'opération.
• Si l'état désiré est verrouillé, PG_locked est nettoyé, mais le compteur de références reste incrémenté.
• Si l'état désiré est déverrouillé, le compteur de références est décrémenté deux fois, une pour la référence courante, et une pour la référence existante qui a obligé la page à rester verrouillée en mémoire. Alors PG_locked est nettoyé.

VI-C-3-d. shm_destroy()

VI-C-3-e. shm_inc()

VI-C-3-f. shm_close()

VI-C-3-g. shmem_file_setup()

VI-D. Les primitives des IPC Linux

VI-D-1. Les primitives génériques des IPC Linux utilisées avec les sémaphores, les messages et la mémoire partagée

VI-D-1-a. ipc_alloc()

VI-D-1-b. ipc_addid()

VI-D-1-c. ipc_rmid()

VI-D-1-d. ipc_buildid()

VI-D-1-e. ipc_checkid()

VI-D-1-f. grow_ary()

VI-D-1-g. ipc_findkey()

VI-D-1-h. ipcperms()

VI-D-1-i. ipc_lock()

VI-D-1-j. ipc_unlock()

VI-D-1-k. ipc_lockall()

VI-D-1-l. ipc_unlockall()

VI-D-1-m. ipc_get()

VI-D-1-n. ipc_parse_version()

VI-D-2. Les structures des IPC génériques utilisées avec les sémaphores, les messages, et la mémoire partagée

VI-D-2-a. struct kern_ipc_perm

/* utilisé par les structures de données internes au noyau */
struct kern_ipc_perm {
    key_t key;
    uid_t uid;
    gid_t gid;
    uid_t cuid;
    gid_t cgid;
    mode_t mode;
    unsigned long seq;
};

VI-D-2-b. struct ipc_ids

struct ipc_ids {
    int size;
    int in_use;
    int max_id;
    unsigned short seq;
    unsigned short seq_max;
    struct semaphore sem;
    spinlock_t ary;
    struct ipc_id* entries;
};

VI-D-2-c. struct ipc_id

struct ipc_id {
    struct kern_ipc_perm* p;
};