corectionsujets

docs/sujets/ft_linux.md

@@ -158,7 +158,7 @@ Encadré : le bonus n’est évalué que si la partie obligatoire est PERFECT. P
 
 ## VI. Rendu et évaluation par les pairs
 
-Rendre le travail dans le dépôt Git, comme d’habitude. Seul le travail présent dans le dépôt est évalué pendant la soutenance. Vérifier les noms de dossiers et de fichiers.
+Rendre le travail dans le dépôt Git, comme d’habitude. Seul le travail présent dans le dépôt est évalué pendant la soutenance. Ne pas hésiter à revérifier les noms de dossiers et de fichiers.
 
 Pour des raisons évidentes, on ne pousse pas la machine virtuelle entière, mais un checksum de l’image disque.
 Exemple donné tel quel :

docs/sujets/kfs-1.md

@@ -28,11 +28,11 @@ Visuels : [C1](captures/01-couverture-42.png), [C2](captures/02-habillage-page.p
 
 Bienvenue dans le premier projet Kernel from Scratch.
 
-Enfin du vrai code. Le sujet suppose qu’on a été agacé par le projet noyau Linux. Dans les sujets Kernel from Scratch, on écrit un noyau from scratch, sans logiciel existant, sans API, ni rien de ce genre.
+Enfin du vrai code. L’auteur est à peu près sûr qu’on a été agacé par le projet noyau Linux. Dans les sujets Kernel from Scratch, on écrit un noyau from scratch (no way ?), sans logiciel existant, sans API, ni rien de ce genre.
 
 Une fois ces projets finis, sur les épaules de cet OS non révolutionnaire, on aura le droit de rire des développeurs Javascript ordinaires, qui, de toute évidence, ne savent rien coder.
 
-Plus sérieusement, ces compétences de programmation noyau sont peu répandues. Prendre le temps de comprendre chaque point. On ne se considère pas « Kernel developer » si on ne connaît que les drivers ou les syscalls, de la même façon qu’un sysadmin ne connaît pas que iptables ou l’installation de logiciels. C’est un ensemble de compétences.
+Plus sérieusement, ces compétences de programmation noyau sont peu répandues dans le monde de l’informatique. Prendre le temps de comprendre chaque point. On ne se déclare pas « Kernel developer » quand on ne connaît que les drivers ou les syscalls, de la même façon qu’un sysadmin ne connaît qu’iptables ou l’installation de logiciels. C’est un paquet de compétences.
 
 Le Kernel From Scratch est découpé en plusieurs projets, chacun sur un aspect précis. Tous sont liés. En codant ces fonctionnalités, garder un noyau souple, et des fonctions qui s’emboîtent. La moitié du temps passé sur ces projets consistera à relier les différents aspects du noyau.
 
@@ -50,7 +50,7 @@ Bonne chance, et surtout, s’amuser.
 - Du code basique pour afficher des choses à l’écran
 - Un noyau « Hello world » basique
 
-Le sujet dit que ce n’est pas tant de code que ça. C’est une introduction au développement noyau.
+En fait, ce n’est pas tant de code que ça. Ce sujet est une introduction au développement noyau. « A (wo)man must learn. »
 
 ## III. Instructions générales
 
@@ -98,7 +98,7 @@ Attention : on CAN utiliser le binaire `ld` de l’hôte, mais on CANNOT utilise
 
 ### III.4 Architecture
 
-L’architecture i386 (x86) est obligatoire.
+L’architecture i386 (x86) est obligatoire (on pourra remercier l’auteur plus tard).
 
 ### III.5 Documentation
 
@@ -124,7 +124,7 @@ Pour la partie lien, créer un fichier linker avec le GNU linker (`ld`). « Some
 
 ### IV.0.2 Makefile
 
-Le Makefile doit compiler tous les sources avec les bons flags et le bon compilateur. Le noyau utilisera au moins deux langages (ASM et celui qu’on choisit), donc les règles du Makefile doivent suivre.
+Le Makefile doit compiler tous les sources avec les bons flags et le bon compilateur. Le noyau utilisera au moins deux langages (ASM et celui qu’on choisit), donc il faut écrire les règles correctement. Le PDF glisse ici : `make (<- joke)`.
 
 Après compilation, tous les objets sont liés pour produire le binaire final du noyau (cf. partie Linker).
 
@@ -145,7 +145,7 @@ Encadré : le bonus n’est évalué que si l’obligatoire est PERFECT. Perfect
 Rendre le travail dans le dépôt GiT, comme d’habitude. Seul le travail présent dans le dépôt est noté en soutenance.
 
 Il faut rendre le code, un Makefile et une image virtuelle basique pour le noyau.
-Attention à cette image : le noyau n’en fait encore rien, inutile qu’elle soit énorme. 10 MB est la borne supérieure.
+Attention à cette image (`Carefull` dans le PDF) : le noyau n’en fait encore rien, inutile qu’elle ait la taille d’un éléphant. 10 MB est la borne supérieure. « deal with it. »
 
 ---
 

docs/sujets/kfs-2.md

@@ -50,13 +50,21 @@ Dans une GDT, on peut trouver :
 - User program data
 - User stack, pour la pile d’appels pendant l’exécution en userland
 
-Ensuite, la pile. Rappel du sujet, en substance : une stack est un type abstrait, avec deux opérations principales, push (ajoute un élément) et pop (retire le dernier élément encore présent). L’ordre de sortie donne l’autre nom, LIFO (last in, first out).
+Le sujet conclut : on voit pourquoi cette structure est vraiment importante dans un noyau.
+
+Ensuite, la pile. Rappel donné tel quel, en anglais dans le PDF, traduit ici :
+
+> En informatique, une stack est un type abstrait qui sert de collection d’éléments, avec deux opérations principales : push, qui ajoute un élément à la collection, et pop, qui retire l’élément ajouté le plus récemment et pas encore retiré. L’ordre de sortie donne l’autre nom, LIFO (last in, first out).
+
+« Get it ? Good. Now, let’s move on. »
 
 ## III. Objectifs
 
 Créer, remplir et lier une Global Descriptor Table dans le noyau.
 
-Le sujet ajoute qu’il faut comprendre comment la mémoire fonctionne vraiment, comment la pile et la RAM fonctionnent, comment les utiliser, les remplir, et les lier au BIOS.
+« Yup, that’s it. Not so much, eh ? »
+
+En fait, il faut comprendre comment la mémoire fonctionne vraiment dans un système, comment la pile et la RAM fonctionnent, comment les utiliser, les remplir, et les lier au BIOS.
 
 Oui, le BIOS. Grâce à GRUB, il aidera beaucoup. Heureusement qu’il est déjà installé.
 
@@ -131,6 +139,8 @@ Pas un shell POSIX, juste un shell minimaliste avec quelques commandes, pour le
 
 Exemple du sujet : y mettre l’affichage de la pile noyau, et d’autres choses comme `reboot`, `halt`, etc.
 
+« Have fun ! »
+
 Encadré PERFECT, identique à KFS-1 : bonus évalué seulement si l’obligatoire est intégralement fonctionnel.
 
 ## VII. Rendu et évaluation par les pairs
@@ -138,7 +148,7 @@ Encadré PERFECT, identique à KFS-1 : bonus évalué seulement si l’obligatoi
 Rendre le travail dans le dépôt Git. Seul le contenu du dépôt est évalué. Vérifier les noms de dossiers et de fichiers.
 
 Rendre le code, un Makefile et une image virtuelle basique pour le noyau.
-Note du sujet : le noyau n’en fait encore rien, donc l’image n’a pas à être énorme. (La borne « 10 MB » est dans la partie obligatoire, pas répétée dans ce paragraphe.)
+Note du sujet, en capitales dans le PDF : le noyau n’en fait encore rien, donc l’image n’a pas à être taillée comme un éléphant. La borne « 10 MB » est dans la partie obligatoire, pas répétée dans ce paragraphe.
 
 ---
 

docs/sujets/little-penguin.md

@@ -62,7 +62,7 @@ Ce « challenge » est une série d’exercices de programmation du noyau Linux,
 
 Retirer les petites roues et construire son propre noyau. Plus question de s’appuyer sur des versions précompilées.
 
-Pour cette tâche, lancer son propre noyau — et utiliser Git.
+Pour cette tâche, il faut faire tourner son propre noyau — et utiliser Git. « Exciting, right? No? Well... okay. »
 
 ### À faire
 
@@ -90,7 +90,7 @@ Créer un module noyau « Hello World » avec le comportement suivant. Bloc reco
 %
 ```
 
-Le module doit compiler sur n’importe quel système. Le sujet signale que c’est un indice de compatibilité de version.
+Attention : le module doit compiler sur n’importe quel système. Le PDF marque l’indice ainsi : `(<– version compatibility hint)`.
 
 ### À rendre
 
@@ -111,13 +111,18 @@ Chaînes exactes : `Hello world!`, `Cleaning up module.`, fichier `main.ko`.
 
 ## VIII. Assignment 03
 
-Modifier le fichier C suivant pour qu’il respecte le style de code Linux (`Documentation/CodingStyle`).
+Bien joué d’être arrivé jusque-là. Le sujet espère qu’on s’amuse encore. On s’ennuie un peu, à force de seulement booter et installer des noyaux ?
+Alors il est temps de quelque chose de plus pédant — histoire de rappeler à quel point ces compilations de noyau sont amusantes.
+
+### À faire
+
+- Modifier le fichier C suivant pour qu’il respecte le style de code Linux (voir `Documentation/CodingStyle`).
 
 ### À rendre
 
 - La version mise à jour du fichier C.
 
-Capture [C4](captures/04-little-penguin-assignment-03-11.png). Transcription (l’indentation du PDF est la référence visuelle) :
+Le fichier est sur la page suivante. Capture [C4](captures/04-little-penguin-assignment-03-11.png). La transcription garde les décalages d’indentation de l’extraction du PDF : ils font partie du fichier à corriger. Si un espace diverge, la capture fait foi.
 
 ```c
 #include    <linux/module.h>
@@ -164,6 +169,9 @@ Chaîne exacte dans le code : `We slept a long time!`
 
 ## IX. Assignment 04
 
+Tu as survécu au chaos du style de code — bien joué.
+Passons à quelque chose de plus « real », parce que le sujet devine qu’on commence à s’ennuyer.
+
 ### À faire
 
 - Modifier le module de l’assignment 01 pour qu’il soit chargé automatiquement quand n’importe quel clavier USB est branché. Le déclencheur est l’outil de hotplug de l’espace utilisateur adapté à la distribution : `depmod`, `kmod`, `udev`, `mdev` ou `systemd`.
@@ -178,10 +186,13 @@ Le sujet dit que ça a l’air simple et que c’est un peu piégeux. Indice : c
 
 ## X. Assignment 05
 
+Bien joué pour le chargement automatique du module. Ces macros de hotplug peuvent être piégeuses, mais les maîtriser est utile, surtout dans du vrai développement noyau.
+En parlant de vrai développement — écrivons du code digne de ce nom.
+
 ### À faire
 
-- Reprendre le module de l’assignment 01 et en faire un driver de périphérique caractère `misc`. L’interface misc est présentée comme un moyen simple de créer un périphérique caractère sans entrer dans sysfs et l’enregistrement de devices.
+- Reprendre le module de l’assignment 01 et en faire un driver de périphérique caractère `misc`. L’interface misc est un moyen très simple de créer un périphérique caractère sans s’emberlificoter dans sysfs et l’enregistrement de devices. Le sujet dit : « Trust me, it’s way easier this way! »
-- Le device misc est créé avec un numéro mineur dynamique. Pas de mineur statique réservé.
+- Le device misc est créé avec un numéro mineur dynamique. Inutile de s’acharner à réserver un mineur statique pour un module de test. Ce serait une corvée pour rien.
 - Implémenter `read` et `write`.
 - Le nœud doit apparaître dans `/dev/fortytwo`.
 - En lecture, le device retourne le login étudiant à l’appelant.
@@ -197,6 +208,11 @@ Libellés exacts : `misc`, `/dev/fortytwo`, `invalid value`.
 
 ## XI. Assignment 06
 
+Bien joué pour le driver misc — plutôt propre et simple, non ?
+Au moment où l’on croyait que le défi ne parlait que de code dans le noyau, on revient à un sujet précédent. Eh oui : reconstruire des noyaux.
+
+Ça reflète la réalité. Les développeurs noyau passent souvent plus de temps à recompiler qu’à écrire du code nouveau. Ce n’est pas glorieux, mais c’est une compétence vitale.
+
 ### À faire
 
 - Télécharger le dernier noyau linux-next. Il change tous les jours : prendre la version la plus récente. Le construire et booter dessus.
@@ -205,16 +221,20 @@ Libellés exacts : `misc`, `/dev/fortytwo`, `invalid value`.
 
 - Le log de boot du noyau.
 
-Le sujet ne définit pas linux-next dans l’énoncé. C’est une partie du défi.
+Qu’est-ce que le noyau linux-next ?
-Indice : la documentation du processus de développement dans `Documentation/development-process/`, dans l’arbre des sources. Le PDF répète cet indice une seconde fois, en plus long : cette lecture doit dire tout ce qu’on n’a jamais voulu savoir sur ce que font les développeurs du noyau Linux et comment ils le font.
+Ça fait partie du défi.
+
+Premier indice, recopié : consulter l’excellente documentation sur le processus de développement du noyau dans `Documentation/development-process/`, dans l’arbre des sources. C’est une bonne lecture — on y apprend beaucoup sur la façon de travailler des développeurs noyau.
+
+Le PDF enchaîne un second indice, presque le même : il faudrait lire l’excellente documentation sur la façon dont le noyau Linux est développé, dans `Documentation/development-process/`, dans les sources elles-mêmes. C’est une très bonne lecture, et elle devrait dire tout ce qu’on n’a jamais voulu savoir sur ce que font les développeurs du noyau Linux, et comment ils le font.
 
 ## XII. Assignment 07
 
-On reviendra à linux-next dans une tâche ultérieure : ne pas supprimer ce répertoire. (Dans ce PDF, aucune tâche après celle-ci ne revient explicitement à linux-next. Assignment 08 et 09 n’en parlent pas. La phrase est quand même dans le sujet.)
+On reviendra au noyau linux-next dans une tâche ultérieure, donc ne pas supprimer ce répertoire : on en aura encore besoin. Pour l’instant, assez de compilations de noyau. Écrivons davantage de code.
 
-Cette tâche ressemble à l’assignment 05. L’interface cette fois est debugfs.
+Cette tâche ressemble à l’assignment 05, où l’on a créé un device misc. Cette fois, une autre interface entre l’utilisateur et le noyau : debugfs.
 
-Le sujet rapporte une rumeur : le créateur de debugfs aurait dit que la seule règle est « There are no rules. »
+La rumeur dit que le créateur de debugfs aurait affirmé que la seule règle est : « There are no rules. » Le sujet propose de tester cette théorie.
 
 La distribution doit monter debugfs sur `/sys/kernel/debug/`. Sinon, la monter avec la commande recopiée :
 
@@ -222,7 +242,7 @@ La distribution doit monter debugfs sur `/sys/kernel/debug/`. Sinon, la monter a
 mount -t debugfs none /sys/kernel/debug/
 ```
 
-L’option `CONFIG_DEBUG_FS` doit être activée dans le noyau.
+Il faut que ce soit activé dans le noyau avec l’option `CONFIG_DEBUG_FS`, parce qu’on en aura besoin pour cette tâche.
 
 ### À faire
 
@@ -241,7 +261,8 @@ L’option `CONFIG_DEBUG_FS` doit être activée dans le noyau.
 
 ## XIII. Assignment 08
 
-Revenir au style de code.
+Bien joué pour cette tâche debugfs.
+On ralentit un peu, et on revient au style de code.
 
 ### À faire
 
@@ -254,7 +275,7 @@ Revenir au style de code.
 Encadré [C5](captures/05-little-penguin-assignment-08-17.png) : « But wait—what is this code supposed to do? »
 Suite : « That’s part of the challenge. Have fun figuring it out! »
 
-Capture du code [C6](captures/05-little-penguin-assignment-08-18.png). Transcription :
+Capture du code [C6](captures/05-little-penguin-assignment-08-18.png). Transcription alignée sur l’extraction du PDF. Le numéro de page imprimé à côté de `module_init` n’appartient pas au code. Si un espace diverge, la capture fait foi.
 
 ```c
 #include    <linux/module.h>
@@ -343,6 +364,9 @@ Le nom du device dans ce fichier est `reverse`, pas `fortytwo`.
 
 ## XIV. Assignment 09
 
+Ouf... Le sujet ne sait pas qui a écrit ce dernier fichier, mais quand même.
+Bref, on retourne écrire quelque chose de plus sensé.
+
 ### À faire
 
 - Créer un module qui liste les points de montage du système, avec le nom associé.
@@ -363,7 +387,9 @@ dev        /dev
 
 - Le code source du module et un Makefile.
 
-Le sujet dit que ce n’est pas dur, mais que ça peut être piégeux. Il renvoie à la documentation sur les points de montage, le listage de répertoires, et le parcours de listes chaînées dans le noyau.
+Ce n’est pas une tâche dure, mais elle peut être piégeuse.
+Le sujet renvoie à la documentation sur les points de montage, le listage de répertoires, et le parcours de listes chaînées dans le noyau.
+Et surtout — s’amuser :)
 
 ## XV. Rendu et évaluation par les pairs