pdfextract

docs/notes/cadrage-ft-linux-en-attente.md

@@ -0,0 +1,59 @@
+# Note figée — cadrage ft_linux (non exécuté)
+
+Statut : **en attente**. Rédigée le 23 octobre 2026, avant toute arborescence de rendu.
+On y revient après l’alignement avec le binôme (QEMU déjà choisi de son côté, puis KFS-1 et KFS-2 en duo).
+
+Le lot décrit ci-dessous n’a pas été créé. Les sujets, eux, sont extraits dans `docs/sujets/`.
+
+Point déjà périmé dans ce texte : le choix « VirtualBox + image `.vdi` ». Le binôme est parti sur QEMU. KFS suggère KVM. Ce choix se retranchera avec le questionnaire, pas avec cette note.
+
+---
+
+## Texte figé de la proposition initiale
+
+Le sujet est **ft_linux** (version 3.6) : construire une distribution Linux minimale, dans une machine virtuelle, qui servira de base aux projets noyau. Le lot ci-dessous est le cadrage seulement.
+
+### Ce que le PDF impose
+
+Objectifs : compiler un noyau, installer les binaires listés, une hiérarchie de fichiers conforme aux standards, et un accès à Internet.
+
+Contraintes notables :
+
+- VM obligatoire (VirtualBox ou VMware). Le dépôt école reçoit un **checksum** de l’image disque (`shasum < disk.vdi`), pas la VM.
+- Noyau **≥ 4.0**, sources dans `/usr/src/kernel-$(version)`.
+- Au moins trois partitions : racine, `/boot`, swap.
+- Chargeur de modules (exemple du sujet : udev).
+- Version du noyau contenant le login : `Linux kernel 4.1.2-<login>`.
+- Hostname = login étudiant.
+- 32 ou 64 bits, au choix.
+- Gestion du système type SysV ou systemd.
+- Bootloader (LILO ou GRUB). Binaire : `vmlinuz-<linux_version>-<login>`.
+- Liste de paquets du chapitre IV (Acl, Bash, GCC, Glibc, GRUB, Sysvinit, Vim, etc.). `vim`, `bash`, `grub` et `udev` sont des exemples remplaçables par un équivalent.
+- Pour l’évaluation : pouvoir télécharger des sources (curl, wget ou équivalent) et installer des paquets.
+- Bonus (X, gestionnaire de fenêtres, etc.) seulement si l’obligatoire est parfait.
+
+Les liens du PDF pointent vers LFS stable (« The Bible »), le FHS 3.0, la LSB, POSIX et le manuel Automake. Pas de maquette ni de schéma technique : les images sont le visuel de couverture et le fond de page 42.
+
+### Lot prévu après accord (toujours pas lancé)
+
+**Dépôt de travail** (racine) : `README.md`, `.gitignore`, et `docs/` (méthode recopiée, sujet, pédagogie).
+
+**Sujet** : le PDF dans `docs/sujets/originaux/ft_linux_subject.pdf`. Traduction dans `docs/sujets/ft_linux.md`.
+
+**Cadrage** dans `docs/pedagogie/` : reprise, cahier des charges, architecture, feuille de route, protocole de test manuel. Pas de `ui.md`. Fiche dépôt et fiche orale plus tard.
+
+**Paquet de rendu** `ft_linux/` : README école et `.gitignore`. Pas de `.env.example`.
+
+Aucun script de build dans ce lot.
+
+### Sept choix proposés, non validés
+
+1. Paquet de rendu : `ft_linux/`.
+2. Git : forme A (dépôt imbriqué dans le paquet, au moment du rendu école).
+3. Cible : VirtualBox, image `.vdi` hors git, checksum seul dans le dépôt. **À revoir : le binôme utilise QEMU.**
+4. Chemin calé sur la liste de paquets : LFS en variante SysV, GRUB, eudev, x86_64, trois partitions (`/`, `/boot`, swap). **Le 64 bits est à revoir : KFS impose i386 pour le noyau écrit en duo.**
+5. Login pour le hostname et le suffixe noyau : `fgras-ca` (déduit du compte, à confirmer).
+6. Version du noyau non figée. Contrainte du sujet : ≥ 4.0. Numéro exact = celui du livre LFS au moment du build.
+7. Bonus (serveur X, bureau) hors périmètre tant que l’obligatoire n’est pas bouclé.
+
+Feuille de route alors envisagée : VM et partitions, paquets dans l’ordre du livre, noyau nommé, GRUB, SysV et eudev, réseau, checklist d’évaluation.

docs/notes/questionnaire-binome.md

@@ -0,0 +1,46 @@
+# Questionnaire binôme — avant de figer ft_linux
+
+Brouillon à envoyer. Chaque question vient d’un écart possible entre son ft_linux déjà commencé et les sujets d’après (Little Penguin solo, puis KFS-1 / KFS-2 ensemble).
+
+Les réponses feront bouger la note [cadrage-ft-linux-en-attente.md](cadrage-ft-linux-en-attente.md), surtout les choix 3 (VirtualBox) et 4 (x86_64, SysV).
+
+---
+
+Salut, je démarre ft_linux. Tu es déjà parti sur QEMU. Comme on se retrouve sur KFS-1 et KFS-2, je préfère coller à ton environnement là où les sujets d’après nous l’imposent. Tu peux répondre court, même par morceaux.
+
+## Où tu en es
+
+1. Tu en es où sur ft_linux (partitions, paquets, noyau déjà booté, réseau) ?
+2. Quel login tu as mis en hostname, et dans le suffixe du noyau (`Linux kernel <version>-<login>`, fichier `vmlinuz-<version>-<login>`) ?
+3. Quelle version de noyau (>= 4.0), et les sources sont bien dans `/usr/src/kernel-$(version)` ?
+
+## Machine virtuelle
+
+4. Quelle commande QEMU tu lances (`qemu-system-i386` ou `qemu-system-x86_64`) ? KVM activé ou non ?
+5. Firmware : BIOS (SeaBIOS) ou UEFI (OVMF) ? KFS-2 déclare la GDT au BIOS, et KFS-1 demande GRUB + en-tête multiboot sur une petite image.
+6. Format du disque (qcow2, raw, autre) ? ft_linux demande un checksum de l’image, l’exemple du sujet est `shasum < disk.vdi`. Tu comptes rendre le checksum de quel fichier ?
+7. Taille du disque, et partitions exactes (au minimum `/`, `/boot`, swap) ?
+
+## Bits et toolchain
+
+8. Ta distro est en 32 ou en 64 bits ? ft_linux laisse le choix. Le noyau qu’on écrira en KFS doit être i386. Si tu es en 64 bits, est-ce que ta toolchain peut déjà produire de l’i386 (`gcc -m32`, binutils, nasm) ?
+9. Tu compiles avec quoi (gcc, clang, autre) ? L’auteur des sujets KFS dit utiliser gcc et nasm. Tu as déjà nasm, ou tu comptes un autre assembleur ?
+
+## Boot et services
+
+10. Bootloader : GRUB ou autre ? Installé en BIOS legacy ?
+11. Init : SysV (le sujet liste Sysvinit) ou systemd ? Chargeur de modules : eudev, autre udev, mdev ?
+12. Ta config noyau a les modules, l’USB et `CONFIG_DEBUG_FS` ? Little Penguin s’en sert (clavier USB, debugfs, `/proc`).
+
+## Installer la suite
+
+13. Comment tu ajoutes un paquet qui n’est pas dans la liste du sujet ? Git n’y est pas, et Little Penguin commence par un clone de l’arbre de Linus, puis linux-next.
+14. Tu as déjà curl ou wget, et un accès Internet depuis la VM ?
+
+## Duo KFS
+
+15. Pour KFS, tu vises quel langage ? Le sujet n’impose rien. Les exemples de doc sont en C, les flags cités sont ceux du C++ (`-fno-exception`, `-fno-rtti`, `-nostdlib`, etc.). Rust ou un autre langage, il faut le décider avant d’écrire KFS-1 : KFS-2 reprend ce code.
+16. Tu sépares déjà le gros disque de la distro et la future image de 10 MB max (code + Makefile + GRUB) que KFS demande de rendre ?
+17. Pour le dépôt du duo : un repo à deux, à partir de KFS-1 ? Tu as déjà un squelette (Makefile, script de lien, boot ASM) ?
+
+Mon login côté hostname sera le mien, pas le tien. Les projets solo gardent chacun leur login (`/dev/fortytwo` en Little Penguin). On ne le grave pas dans le code KFS.

docs/sujets/README.md

@@ -0,0 +1,33 @@
+# Sujets du parcours
+
+Ordre réel : **ft_linux** (solo) → **Little Penguin** (solo, sur la distro) → **KFS-1** puis **KFS-2** (duo, le second reprend le code du premier).
+
+Le PDF reste la source si une traduction hésite. Les originaux de la racine n’ont pas été déplacés. Une copie renommée est dans `originaux/`.
+
+| Ordre | Sujet | Traduction | PDF |
+|-------|--------|------------|-----|
+| 1 | ft_linux 3.6 | [ft_linux.md](ft_linux.md) | [originaux/ft_linux_subject.pdf](originaux/ft_linux_subject.pdf) |
+| 2 | Little Penguin 1.1 | [little-penguin.md](little-penguin.md) | [originaux/little_penguin_subject.pdf](originaux/little_penguin_subject.pdf) |
+| 3 | KFS-1 v1 | [kfs-1.md](kfs-1.md) | [originaux/kfs-1_subject.pdf](originaux/kfs-1_subject.pdf) |
+| 4 | KFS-2 v2 | [kfs-2.md](kfs-2.md) | [originaux/kfs-2_subject.pdf](originaux/kfs-2_subject.pdf) |
+
+Images : [captures/README.md](captures/README.md).
+
+Le cadrage ft_linux proposé avant cette lecture est figé dans [../notes/cadrage-ft-linux-en-attente.md](../notes/cadrage-ft-linux-en-attente.md). Il n’est pas lancé. Les questions pour le binôme sont dans [../notes/questionnaire-binome.md](../notes/questionnaire-binome.md).
+
+## Ce que les sujets suivants imposent déjà à ft_linux
+
+Faits lus dans les PDF, pas des préférences.
+
+1. **Little Penguin se fait sur la distro de ft_linux.** Pas sur la machine hôte. La distro doit compiler un noyau, le booter, charger des modules, et installer ce qui manque.
+2. **Git n’est pas dans la liste de paquets de ft_linux.** Little Penguin commence par cloner l’arbre de Linus sur git.kernel.org, puis linux-next. Le sujet ft_linux exige de pouvoir télécharger des sources et installer des paquets. La méthode d’installation compte autant que la liste du chapitre IV.
+3. **Deux noyaux différents.** Celui de la distro porte le login (`vmlinuz-<linux_version>-<login>`, sources dans `/usr/src/kernel-$(version)`). Ceux de Little Penguin sont d’autres arbres (Linus, puis linux-next), avec `CONFIG_LOCALVERSION_AUTO=y` et, plus tard, `-thor_kernel` dans la version.
+4. **La config du noyau de la distro sert encore après ft_linux.** Little Penguin demande des modules, l’USB (clavier, assignment 04), `CONFIG_DEBUG_FS`, `/proc`, `/sys`, `/dev`.
+5. **L’init choisit le fichier de règles.** Assignment 04 : hotplug via `depmod`, `kmod`, `udev`, `mdev` ou `systemd`, selon la distribution. SysV + eudev et systemd satisfont tous deux le texte de ft_linux. Ils ne produisent pas le même fichier de règles.
+6. **KFS n’est pas la distro.** On rend un code, un Makefile et une image virtuelle à part, au plus 10 MB, avec GRUB dessus. Le gros disque de ft_linux reste l’hôte de build et le support de Little Penguin.
+7. **Le noyau qu’on écrit en KFS est i386.** ft_linux laisse le choix 32 ou 64 bits pour la distro. KFS-1 et KFS-2 imposent i386 pour le noyau du projet. Une distro 64 bits doit pouvoir produire un binaire i386 (multiboot). Une distro 32 bits le fait nativement.
+8. **GRUB et le BIOS sont déjà là au début de KFS-2.** KFS-1 installe GRUB sur la petite image et demande un en-tête multiboot. KFS-2 déclare la GDT au BIOS et rappelle que GRUB est déjà installé. Un boot uniquement UEFI ne sert pas cet énoncé.
+9. **KVM est la suggestion de KFS, pas une obligation.** « N’importe quel » gestionnaire de virtuel convient. Les exemples du sujet utilisent KVM. QEMU est dans cette famille. L’exemple `disk.vdi` de ft_linux est un exemple de checksum, pas un format imposé : le sujet demande un checksum de l’image disque.
+10. **Le langage du duo se choisit avant KFS-1.** Aucun langage n’est imposé. Les docs sont en C. L’auteur dit utiliser gcc et nasm. Les flags cités sont un exemple C++. KFS-2 reprend le code de KFS-1, ou le réécrit entièrement. Les fonctions qui ont besoin d’un allocateur (`new`, etc.) ne sont pas utilisables au début.
+11. **Le login étudiant reste personnel sur les projets solo.** Hostname et suffixe de noyau (ft_linux), chaîne lue et écrite sur `/dev/fortytwo` et sur debugfs `id` (Little Penguin). KFS affiche `42`, pas le login. Le code commun du duo n’a pas de login à graver.
+12. **Le bonus graphique de ft_linux n’aide pas KFS.** KFS-1 écrit à l’écran par sa propre interface, sans serveur X. Le bonus X n’est évalué que si ft_linux obligatoire est parfait.

docs/sujets/captures/README.md

@@ -0,0 +1,16 @@
+# Captures des sujets
+
+Index des images extraites des PDF. Le même visuel sert plusieurs sujets : un seul fichier, plusieurs renvois.
+
+Les PDF d’origine restent la référence si un détail de mise en page compte (surtout les fichiers C de Little Penguin, dont le style est volontairement cassé).
+
+| Id | Fichier | Où ça apparaît | Ce que montre l’image |
+|----|---------|----------------|------------------------|
+| C1 | [01-couverture-42.png](01-couverture-42.png) | Page de titre de ft_linux, Little Penguin, KFS-1 et KFS-2 | Marque 42 : bande verticale de triangles gris sur fond noir. Habillage, pas une consigne. |
+| C2 | [02-habillage-page.png](02-habillage-page.png) | Toutes les pages intérieures | Filigrane géométrique gris pâle. Aucun schéma, aucune arborescence imposée. |
+| C3 | [03-kfs-choose-wisely.png](03-kfs-choose-wisely.png) | KFS-1, fin de III.1.2 Language (page 4 du PDF paginé). KFS-2, même endroit dans les instructions générales | Mème : chevalier du Graal, légende « YOU MUST CHOOSE... BUT CHOOSE WISELY. » Illustre la phrase du sujet sur le choix du langage. Pas une spec technique. |
+| C4 | [04-little-penguin-assignment-03-11.png](04-little-penguin-assignment-03-11.png) | Little Penguin, Assignment 03, page 10 | Fichier C à remettre au style du noyau. Fond noir, coloration syntaxique. Source visuelle du code. |
+| C5 | [05-little-penguin-assignment-08-17.png](05-little-penguin-assignment-08-17.png) | Little Penguin, Assignment 08, page 16 | Énoncé, et encadré : « But wait—what is this code supposed to do? » Le comportement à corriger n’est pas décrit. |
+| C6 | [05-little-penguin-assignment-08-18.png](05-little-penguin-assignment-08-18.png) | Little Penguin, page 17 | Fichier C du device `reverse` à restyler et à corriger. |
+
+Aucune maquette d’interface, aucun schéma de partitions, aucun diagramme de boot dans les quatre PDF.

docs/sujets/ft_linux.md

@@ -0,0 +1,208 @@
+# ft_linux — how_to_train_your_kernel
+
+Traduction française du sujet. Le PDF reste la source en cas de doute.
+
+| | |
+|--|--|
+| Fichier d’origine à la racine | `sujet_ft_linux.pdf` |
+| Copie de travail | [originaux/ft_linux_subject.pdf](originaux/ft_linux_subject.pdf) |
+| Version | 3.6 |
+| Date du PDF | 7 novembre 2025 |
+| Pages | 10 |
+| Résumé (anglais, page de titre) | Make your own linux distribution |
+
+Visuels : [C1](captures/01-couverture-42.png) en couverture, [C2](captures/02-habillage-page.png) en filigrane. Pas de figure technique.
+
+## Liens réellement posés dans le PDF
+
+| Ancre anglaise | Cible |
+|----------------|--------|
+| `standards` (objectifs : hiérarchie « compliant with the standards ») | <http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> |
+| `The Bible` | <http://www.linuxfromscratch.org/lfs/view/stable/index.html> |
+| `Autotools` | <https://www.gnu.org/software/automake/manual/html_node/index.html#SEC_Contents> |
+| `this` (« you SHOULD read this and that ») | <http://pubs.opengroup.org/onlinepubs/9699919799/> |
+| `that` | <http://refspecs.linuxfoundation.org/lsb.shtml> |
+
+La phrase « How to build a Linux kernel » n’est pas un lien.
+
+---
+
+## I. Introduction
+
+Bienvenue dans ft_linux. Dans ce sujet, il faut construire une distribution Linux basique, mais fonctionnelle.
+
+Ce sujet ne porte pas sur la programmation du noyau, mais il y est fortement lié.
+Cette distribution sera la base de tous les projets noyau, parce que tout le code noyau sera exécuté ici, sur cette distribution.
+Essayer d’implémenter ce que l’on veut ou dont on a besoin. C’est l’espace utilisateur, il faut en prendre soin.
+
+## II. Objectifs
+
+- Construire un noyau Linux
+- Installer quelques binaires (voir la liste plus bas)
+- Mettre en place une hiérarchie de fichiers conforme aux standards (`standards` → FHS 3.0)
+- Se connecter à Internet
+
+## III. Instructions générales
+
+### III.0.1 Ressources
+
+- The Bible (lien vers LFS stable)
+- Comment construire un noyau Linux : il existe en fait beaucoup de ressources en ligne qui décrivent diverses recettes pas à pas pour configurer, construire et lancer un noyau Linux personnalisé.
+- Autotools (lien vers le manuel Automake)
+
+### III.0.2 Instructions
+
+- Pour ce sujet, il faut utiliser une machine virtuelle. Par exemple VirtualBox ou VMWare.
+- Ce n’est pas REQUIRED, mais on SHOULD lire `this` et `that` tout de suite (POSIX et LSB). Garder ces standards en tête. On ne sera pas noté sur leur respect, mais ce serait une bonne pratique.
+- Il faut un noyau en version >= 4.0. Stable ou non, du moment que la version est >= 4.0.
+- Les sources du noyau doivent être dans `/usr/src/kernel-$(version)`.
+- Il faut au moins 3 partitions différentes : root, `/boot` et une partition de swap. On peut bien sûr en faire davantage.
+- La distribution doit implémenter un `kernel_module` loader, comme udev.
+- La version du noyau doit contenir le login étudiant. Quelque chose comme `Linux kernel 4.1.2-<student_login>`.
+- Le hostname de la distribution doit être le login étudiant.
+- Liberté de choisir un système 32 ou 64 bits.
+- Il faut un logiciel de gestion et de configuration centrale, comme SysV ou SystemD.
+- La distribution doit démarrer avec un bootloader, comme LILO ou GRUB.
+- Le binaire du noyau situé dans `/boot` doit être nommé ainsi : `vmlinuz-<linux_version>-<student_login>`. Adapter la configuration du bootloader en conséquence.
+
+## IV. Partie obligatoire
+
+### IV.0.1 Paquets à installer
+
+Encadré du sujet : certains paquets ci-dessous (`vim`, `bash`, `grub`, `udev`) sont des exemples. On peut les remplacer par n’importe quel équivalent. Les versions sont libres.
+
+Noms recopiés tels quels :
+
+- Acl
+- Attr
+- Autoconf
+- Automake
+- Bash
+- Bc
+- Binutils
+- Bison
+- Bzip2
+- Check
+- Coreutils
+- DejaGNU
+- Diffutils
+- Eudev
+- E2fsprogs
+- Expat
+- Expect
+- File
+- Findutils
+- Flex
+- Gawk
+- GCC
+- GDBM
+- Gettext
+- Glibc
+- GMP
+- Gperf
+- Grep
+- Groff
+- GRUB
+- Gzip
+- Iana-Etc
+- Inetutils
+- Intltool
+- IPRoute2
+- Kbd
+- Kmod
+- Less
+- Libcap
+- Libpipeline
+- Libtool
+- M4
+- Make
+- Man-DB
+- Man-pages
+- MPC
+- MPFR
+- Ncurses
+- Patch
+- Perl)
+- Pkg-config
+- Procps
+- Psmisc
+- Readline
+- Sed
+- Shadow
+- Sysklogd
+- Sysvinit
+- Tar
+- Tcl
+- Texinfo
+- Time Zone Data
+- Udev-lfs Tarball
+- Util-linux
+- Vim
+- XML::Parser
+- Xz Utils
+- Zlib
+
+La parenthèse de `Perl)` est dans le PDF.
+
+Encadré : pour l’évaluation, il faut pouvoir télécharger du code source. Le sujet recommande fortement d’installer curl, wget, ou un autre outil.
+
+Encadré : pour l’évaluation, il faut aussi pouvoir installer des paquets. Avoir tout ce qu’il faut pour ça.
+
+## V. Partie bonus
+
+Le système est stable ? Bien. On peut s’amuser. Installer ce que l’on veut. N’importe quel logiciel, une GUI, ANYTHING.
+Faire de ce système le sien, avec sa touche. (La phrase est répétée deux fois dans le PDF.)
+Points particuliers pour un serveur X, et des gestionnaires de fenêtres ou environnements de bureau, comme GNOME / LXDE / KDE / i3 / dwm...
+
+Encadré : le bonus n’est évalué que si la partie obligatoire est PERFECT. Perfect veut dire que l’obligatoire est intégralement fait et fonctionne sans dysfonctionnement. Si tous les prérequis obligatoires ne sont pas validés, le bonus n’est pas évalué du tout.
+
+## 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.
+
+Pour des raisons évidentes, on ne pousse pas la machine virtuelle entière, mais un checksum de l’image disque.
+Exemple donné tel quel :
+
+```text
+shasum < disk.vdi
+```
+
+Garder l’image disque quelque part pour l’évaluation par les pairs.
+
+---
+
+## Grille de lecture
+
+### Obligatoire
+
+- Distribution Linux basique et fonctionnelle, dans une machine virtuelle.
+- Noyau construit, version >= 4.0, sources dans `/usr/src/kernel-$(version)`.
+- Version du noyau contenant le login. Forme citée : `Linux kernel 4.1.2-<student_login>`.
+- Fichier dans `/boot` : `vmlinuz-<linux_version>-<student_login>`, bootloader adapté.
+- Hostname = login étudiant.
+- Au moins les partitions root, `/boot` et swap.
+- Chargeur de modules du type udev.
+- Logiciel de gestion centrale du type SysV ou SystemD.
+- Bootloader du type LILO ou GRUB.
+- Binaires de la liste du chapitre IV, ou équivalents pour les exemples cités (`vim`, `bash`, `grub`, `udev`).
+- Hiérarchie de fichiers conforme aux standards (lien FHS).
+- Accès à Internet.
+- Pouvoir télécharger des sources et installer des paquets.
+- Au rendu : checksum de l’image disque, pas la VM. L’image reste disponible pour la soutenance.
+
+### Bonus
+
+- Logiciels au choix, interface graphique.
+- Serveur X, gestionnaires de fenêtres ou bureaux : GNOME, LXDE, KDE, i3, dwm, etc.
+- Évalué seulement si l’obligatoire est parfait.
+
+### Interdit, ou explicitement non noté
+
+- Pousser la machine virtuelle entière.
+- Noyau de version inférieure à 4.0.
+- Le respect de POSIX et de la LSB n’est pas noté. Le sujet demande quand même de les lire.
+- Bonus non regardé si l’obligatoire n’est pas intégralement fonctionnel.
+
+### Libellés et chemins à garder tels quels
+
+`REQUIRED`, `SHOULD`, `PERFECT`, `ANYTHING`, `kernel_module`, `student_login`, `linux_version`, `/usr/src/kernel-$(version)`, `/boot`, `vmlinuz-<linux_version>-<student_login>`, `Linux kernel 4.1.2-<student_login>`, `shasum < disk.vdi`, et tous les noms de paquets de la liste.

docs/sujets/kfs-1.md

@@ -0,0 +1,185 @@
+# KFS_1 — Grub, boot and screen
+
+Traduction française du sujet. Le PDF reste la source en cas de doute.
+
+| | |
+|--|--|
+| Fichier d’origine à la racine | `kfs-1sujet.pdf` |
+| Copie de travail | [originaux/kfs-1_subject.pdf](originaux/kfs-1_subject.pdf) |
+| Auteurs | 42 Staff, pedago@42.fr |
+| Version | 1 |
+| Date du PDF | 26 juillet 2022 |
+| Pages | 9 |
+| Résumé (anglais) | The real code ! |
+
+Visuels : [C1](captures/01-couverture-42.png), [C2](captures/02-habillage-page.png), et [C3](captures/03-kfs-choose-wisely.png) à la fin de la section langage.
+
+## Liens
+
+| Ancre | Cible |
+|-------|--------|
+| `pedago@42.fr` | mailto |
+| `OSDev` (phrase « the OSDev wiki is one of the best ») | <http://wiki.osdev.org/Main_Page> |
+| `here` (phrase « Some docs here. ») | <http://www.math.utah.edu/docs/info/ld_3.html#SEC4> |
+
+---
+
+## I. Introduction
+
+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.
+
+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.
+
+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.
+
+Exemple du sujet : il faut écrire le code mémoire avant le code des processus et de l’exécution. Mais les processus utilisent la mémoire. Il faut donc relier les deux. Garder le code *clean*, et l’API interne simple.
+
+Bonne chance, et surtout, s’amuser.
+
+## II. Objectifs
+
+À la fin de ce sujet, on a :
+
+- Un noyau bootable via GRUB
+- Une base bootable en ASM
+- Une bibliothèque noyau basique, avec des fonctions et des types de base
+- 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.
+
+## III. Instructions générales
+
+### III.1 Code et exécution
+
+#### III.1.1 Émulation
+
+Cette partie n’est pas obligatoire. N’importe quel gestionnaire de machines virtuelles convient. Le sujet suggère KVM : un Kernel Virtual Manager, avec des fonctions avancées d’exécution et de debug. Tous les exemples du sujet utilisent KVM.
+
+#### III.1.2 Langage
+
+Aucun sujet Kernel from Scratch n’impose le langage.
+Le C n’est pas obligatoire. Tous les langages ne sont pas adaptés à un noyau. On pourrait coder un noyau en Javascript ; le sujet demande si c’est une bonne idée.
+Beaucoup d’exemples dans les documentations sont en C. Choisir un autre langage implique de traduire du code en permanence.
+Toutes les fonctionnalités d’un langage ne sont pas utilisables dans un noyau basique.
+Exemple C++ : `new` sert aux allocations, aux classes et aux déclarations de structures. Le noyau n’a pas encore d’interface mémoire, donc ces fonctionnalités sont inutilisables au début.
+Beaucoup de langages peuvent remplacer le C : C++, Rust, Go, etc. On peut même tout écrire en ASM.
+Choisir un langage, mais choisir judicieusement.
+
+Image [C3](captures/03-kfs-choose-wisely.png) placée ici : « YOU MUST CHOOSE... BUT CHOOSE WISELY. »
+
+### III.2 Compilation
+
+#### III.2.1 Compilateurs
+
+N’importe quel compilateur. L’auteur utilise personnellement gcc et nasm. Un Makefile doit être rendu.
+
+#### III.2.2 Flags
+
+Pour booter sans dépendance, compiler avec les flags suivants. Les adapter au langage. Ceux-ci sont un exemple C++ :
+
+- `-fno-builtin`
+- `-fno-exception`
+- `-fno-stack-protector`
+- `-fno-rtti`
+- `-nostdlib`
+- `-nodefaultlibs`
+
+Attention à `-nodefaultlibs` et `-nostdlib`. Le noyau est compilé sur un système hôte, mais il ne peut être lié à aucune bibliothèque de cet hôte, sinon il ne s’exécutera pas.
+
+### III.3 Édition de liens
+
+On ne peut pas utiliser un linker existant pour lier le noyau. Comme écrit plus haut, le noyau ne booterait pas. Il faut créer un linker pour le noyau.
+Attention : on CAN utiliser le binaire `ld` de l’hôte, mais on CANNOT utiliser le fichier `.ld` de l’hôte.
+
+### III.4 Architecture
+
+L’architecture i386 (x86) est obligatoire.
+
+### III.5 Documentation
+
+Il existe beaucoup de documentation, bonne et mauvaise. L’auteur estime que le wiki OSDev est l’une des meilleures. Le mot `OSDev` pointe vers <http://wiki.osdev.org/Main_Page>.
+
+## IV. Partie obligatoire
+
+### IV.0.1 Base
+
+Faire un noyau, bootable avec GRUB, capable d’écrire des caractères à l’écran.
+Pour cela :
+
+- Installer GRUB sur une image virtuelle
+- Écrire un code de boot ASM qui gère l’en-tête multiboot, et utiliser GRUB pour initialiser et appeler la fonction main du noyau
+- Écrire le code noyau de base dans le langage choisi
+- Le compiler avec les bons flags, et le lier pour le rendre bootable
+- Une fois ces étapes faites, on peut écrire des helpers : types noyau, ou fonctions de base (`strlen`, `strcmp`, ...)
+- Le travail ne doit pas dépasser 10 MB
+- Coder l’interface entre le noyau et l’écran
+- Afficher `42` à l’écran
+
+Pour la partie lien, créer un fichier linker avec le GNU linker (`ld`). « Some docs here. » : le mot `here` pointe vers la doc de `ld`, section scripts.
+
+### 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.
+
+Après compilation, tous les objets sont liés pour produire le binaire final du noyau (cf. partie Linker).
+
+## V. Partie bonus
+
+Suppléments présentés comme utiles :
+
+- Ajouter le défilement et le curseur à l’interface d’E/S
+- Ajouter les couleurs à l’interface d’E/S
+- Ajouter des helpers comme `printf` / `printk` pour afficher des informations et débugger facilement
+- Gérer les entrées clavier et les afficher
+- Gérer plusieurs écrans, et des raccourcis clavier pour passer de l’un à l’autre
+
+Encadré : le bonus n’est évalué que si l’obligatoire est PERFECT. Perfect veut dire intégralement fait et sans dysfonctionnement. Sinon le bonus n’est pas évalué du tout.
+
+## 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 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.
+
+---
+
+## Grille de lecture
+
+### Obligatoire
+
+- Noyau bootable par GRUB, en-tête multiboot, boot ASM qui appelle `main`.
+- GRUB installé sur l’image virtuelle.
+- Architecture i386 (x86).
+- Au moins ASM plus le langage choisi. Makefile rendu.
+- Flags adaptés au langage. L’exemple C++ est la liste ci-dessus. Pas de lien vers les bibliothèques de l’hôte (`-nostdlib`, `-nodefaultlibs`).
+- Script de lien écrit pour ce noyau. Le binaire `ld` de l’hôte est autorisé. Le fichier `.ld` de l’hôte ne l’est pas.
+- Afficher la chaîne `42` à l’écran.
+- Travail (et image) ne dépassant pas 10 MB.
+- Rendu : code, Makefile, image virtuelle basique.
+
+### Bonus
+
+- Scroll et curseur.
+- Couleurs.
+- `printf` / `printk`.
+- Clavier : lire une touche et l’afficher.
+- Plusieurs écrans, raccourcis pour changer.
+- Évalué seulement si l’obligatoire est parfait.
+
+### Interdit
+
+- Lier le noyau à une bibliothèque de l’hôte.
+- Réutiliser le fichier `.ld` de l’hôte.
+- Dépasser 10 MB.
+- Traiter l’émulation comme une techno imposée : KVM est suggéré, pas obligatoire.
+- Bonus si l’obligatoire n’est pas parfait.
+
+### Libellés exacts
+
+`42`, `main`, `strlen`, `strcmp`, `printf`, `printk`, `-fno-builtin`, `-fno-exception`, `-fno-stack-protector`, `-fno-rtti`, `-nostdlib`, `-nodefaultlibs`, `ld`, multiboot, GRUB, KVM, i386, `10 MB`, `CAN`, `CANNOT`, `PERFECT`.

docs/sujets/kfs-2.md

@@ -0,0 +1,166 @@
+# KFS_2 — GDT & Stack
+
+Traduction française du sujet. Le PDF reste la source en cas de doute.
+
+| | |
+|--|--|
+| Fichier d’origine à la racine | `kfs-2sujet.pdf` |
+| Copie de travail | [originaux/kfs-2_subject.pdf](originaux/kfs-2_subject.pdf) |
+| Auteurs | 42 Staff, pedago@42.fr |
+| Version | 2 |
+| Date du PDF | 26 juillet 2022 |
+| Pages | 10 |
+| Résumé (anglais) | Let’s code the stack ! |
+
+Visuels : [C1](captures/01-couverture-42.png), [C2](captures/02-habillage-page.png), et la même image [C3](captures/03-kfs-choose-wisely.png) dans la section langage. Pas de schéma de GDT.
+
+## Liens
+
+| Ancre | Cible |
+|-------|--------|
+| `pedago@42.fr` | mailto |
+| `OSDev` | <http://wiki.osdev.org/Main_Page> |
+
+Ce PDF ne reprend pas le lien « Some docs here » vers la doc de `ld`.
+
+---
+
+## I. Avant-propos
+
+Le chapitre I est une blague (rotations de classes d’un jeu, patch 6.2.4). Il ne pose aucune exigence. Libellés gardés :
+
+- Hunter 6.2.4 Rotation : `Barrage`, `Aspect of the pack`, `Die`, `Blame the heal`
+- Rogue 6.2.4 Rotation : `Pull without the tank`, `Die`, `Blame the heal`
+- Warrior tank 6.2.4 Rotation : `Pull the entire dungeon`, `Die`, `Blame the heal`
+- Druid Heal 6.2.4 Rotation : `Blame the other heal`
+- Death Knight 6.2.4 Rotation : `Roll`, `Your`, `Head`, `On`, `The`, `Keyboard`
+
+## II. Introduction
+
+Deuxième sujet Kernel from Scratch. Cette fois, coder une pile, et l’intégrer à la GDT.
+
+Définition donnée par le sujet. La GDT (« Global Descriptor Table ») est une structure de données qui définit les différentes zones mémoire : adresse de base, taille, et privilèges d’accès comme l’exécution et l’écriture. Ces zones s’appellent des « segments ».
+
+Dans une GDT, on peut trouver :
+
+- Kernel code, pour stocker le code binaire exécutable
+- Kernel data
+- Kernel stack, pour la pile d’appels pendant l’exécution du noyau
+- User code, pour le code binaire exécutable des programmes utilisateur
+- 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).
+
+## 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.
+
+Oui, le BIOS. Grâce à GRUB, il aidera beaucoup. Heureusement qu’il est déjà installé.
+
+## IV. Instructions générales
+
+Même cadre que KFS-1, avec quelques formulations différentes.
+
+### IV.1.1 Émulation
+
+Partie non obligatoire. N’importe quel gestionnaire de virtuel convient. KVM est suggéré. Les exemples du sujet utilisent KVM.
+
+### IV.1.2 Langage
+
+Le C n’est pas obligatoire pour cette suite de projets. Les documentations sont souvent en C : un autre langage implique de traduire. Exemple C++ : `new` et les classes exigent une interface mémoire que le noyau n’a pas encore. C++, Rust, Go, ou même tout en ASM, sont cités.
+
+Image [C3](captures/03-kfs-choose-wisely.png) au même endroit que dans KFS-1.
+
+### IV.2 Compilation
+
+Compilateur libre. L’auteur utilise gcc et nasm. Un Makefile doit être ajouté au dépôt.
+
+Mêmes flags, présentés comme un exemple C++ :
+
+- `-fno-builtin`
+- `-fno-exception`
+- `-fno-stack-protector`
+- `-fno-rtti`
+- `-nostdlib`
+- `-nodefaultlibs`
+
+Pas de lien vers une bibliothèque de l’hôte, sinon le noyau ne s’exécute pas.
+
+### IV.3 Édition de liens
+
+Il faut créer un linker pour le noyau. On CAN utiliser le binaire `ld` de l’hôte. Il est FORBIDDEN d’utiliser le fichier `.ld` de l’hôte. (KFS-1 disait CANNOT ; KFS-2 dit FORBIDDEN.)
+
+### IV.4 Architecture
+
+i386 (x86) obligatoire.
+
+### IV.5 Documentation
+
+Le wiki OSDev est recommandé par l’auteur. Lien sur le mot `OSDev`.
+
+### IV.6 Code de base
+
+Il faut prendre le code KFS précédent et travailler à partir de lui.
+Ou pas... et tout réécrire depuis le début. Au choix.
+
+## V. Partie obligatoire
+
+Récapitulatif du sujet :
+
+- Créer une Global Descriptor Table.
+- La GDT doit contenir :
+  - Kernel Code
+  - Kernel Data
+  - Kernel stack
+  - User code
+  - User data
+  - User stack
+  - Le travail ne devrait pas dépasser 10 MB. (La puce est indentée dans la liste de la GDT, dans le PDF.)
+- Déclarer la GDT au BIOS.
+- La GDT doit être placée à l’adresse `0x00000800`.
+
+Ensuite, coder un outil pour afficher la pile noyau, de façon lisible par un humain. Astuce du sujet : si `printk` n’existe pas encore, c’est le moment.
+
+## VI. Partie bonus
+
+En supposant que le clavier fonctionne correctement dans le noyau, et qu’on sache capter une entrée, coder un Shell.
+Pas un shell POSIX, juste un shell minimaliste avec quelques commandes, pour le debug.
+
+Exemple du sujet : y mettre l’affichage de la pile noyau, et d’autres choses comme `reboot`, `halt`, etc.
+
+Encadré PERFECT, identique à KFS-1 : bonus évalué seulement si l’obligatoire est intégralement fonctionnel.
+
+## VII. Rendu et évaluation par les pairs
+
+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.)
+
+---
+
+## Grille de lecture
+
+### Obligatoire
+
+- Repartir du code KFS-1, ou le réécrire. Le sujet laisse les deux.
+- GDT créée, remplie, liée au noyau, déclarée au BIOS, posée à `0x00000800`.
+- Six descripteurs nommés : Kernel Code, Kernel Data, Kernel stack, User code, User data, User stack.
+- Outil d’affichage de la pile noyau, lisible.
+- i386, GRUB déjà là, image et travail dans la limite de 10 MB.
+- Makefile, code, image virtuelle basique.
+- Même interdiction de lien : binaire `ld` autorisé, fichier `.ld` de l’hôte forbidden.
+
+### Bonus
+
+- Shell minimal de debug, pas POSIX.
+- Exemples de commandes cités : affichage de la pile, `reboot`, `halt`.
+- Le sujet suppose que le clavier du bonus KFS-1 fonctionne.
+- Évalué seulement si l’obligatoire est parfait.
+
+### Libellés exacts
+
+`Global Descriptor Table`, `GDT`, `0x00000800`, `Kernel Code`, `Kernel Data`, `Kernel stack`, `User code`, `User data`, `User stack`, `printk`, `reboot`, `halt`, `push`, `pop`, `LIFO`, `BIOS`, `GRUB`, `FORBIDDEN`, `10 MB`.

docs/sujets/little-penguin.md

@@ -0,0 +1,416 @@
+# Little Penguin — Linux Kernel Development
+
+Traduction française du sujet. Le PDF reste la source en cas de doute.
+Les sorties de commandes, les noms de fichiers et les deux fichiers C sont recopiés. Pour le style (espaces, retours), les captures C4 et C6 font foi : l’extraction texte aplatit une partie de l’indentation, et c’est justement ce style qu’il faudra corriger.
+
+| | |
+|--|--|
+| Fichier d’origine à la racine | `little_pinguin sujet.pdf` |
+| Copie de travail | [originaux/little_penguin_subject.pdf](originaux/little_penguin_subject.pdf) |
+| Auteurs | Louis Solofrizzo louis@ne02ptzero.me, 42 Staff pedago@42.fr |
+| Version | 1.1 |
+| Date du PDF | 9 mai 2025 |
+| Pages | 20 |
+| Résumé (anglais) | This entire project is based on the Eudyptula Challenge. All credits go to little@eudyptula-challenge.org |
+
+Visuels : [C1](captures/01-couverture-42.png), [C2](captures/02-habillage-page.png), [C4](captures/04-little-penguin-assignment-03-11.png), [C5](captures/05-little-penguin-assignment-08-17.png), [C6](captures/05-little-penguin-assignment-08-18.png).
+
+## Liens
+
+| Ancre | Cible |
+|-------|--------|
+| `louis@ne02ptzero.me` | mailto |
+| `pedago@42.fr` | mailto |
+| URL de la page de titre | <http://eudyptula-challenge.org/> |
+
+`Linux Device Drivers, 3rd Edition` est cité au chapitre 14, sans URL dans le PDF. Les chemins `Documentation/...` sont des chemins dans l’arbre des sources du noyau, pas des liens web.
+
+---
+
+## I. Préambule
+
+### I.1 Extrait de `Documentation/CodingStyle`
+
+Le PDF colle un extrait du style de code du noyau Linux.
+
+Le style est personnel. L’auteur de ce document ne force pas ses vues, mais c’est le standard de ce qu’il maintient, et il préférerait qu’il s’applique à la plupart des autres projets. Au moins considérer ces points.
+
+D’abord, imprimer les GNU coding standards, puis ne pas les lire. Les brûler — c’est un beau geste symbolique.
+Le PDF ajoute : « ;) ok, it’s definitely not an eco-responsible move. »
+
+Chapitre 1 : Indentation.
+
+Les tabulations font 8 caractères de large, donc les indentations aussi. Des tentatives utilisent 4, voire 2 caractères. Le texte compare ça à définir PI comme valant 3.
+
+## II. Introduction
+
+Ce « challenge » est une série d’exercices de programmation du noyau Linux, qui commence petit et monte en complexité. Si tout se passe bien, à la fin on sera assez qualifié pour maintenir un sous-système, si on le souhaite. Peut-être pas mainteneur complet, mais assez compétent pour identifier les problèmes causés par son mainteneur préféré. Ce qui peut être encore plus amusant que d’être aux commandes.
+
+## III. Objectifs
+
+- Compiler un noyau personnalisé.
+- Construire et utiliser un module noyau.
+- Apprendre comment les drivers fonctionnent sous Linux.
+
+## IV. Instructions générales
+
+- Ce sujet ressemble à une journée de Piscine. Certaines tâches sont assez difficiles : prendre son temps.
+- Tout le travail doit être fait sur la distribution Linux personnalisée. Si on n’en a pas, le sujet demande ce qu’on fait là.
+- Attention. Certaines tâches ne demandent pas de rendre du code, mais une forme de preuve.
+
+## V. Assignment 00
+
+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.
+
+### À faire
+
+- Télécharger le dernier arbre Git de Linus depuis git.kernel.org. Il faut trouver lequel est le sien. Le sujet dit que ce n’est pas dur : se souvenir de son nom de famille.
+- Le construire, l’installer et booter dessus. La configuration est libre, mais il faut activer `CONFIG_LOCALVERSION_AUTO=y`.
+
+### À rendre
+
+- Le fichier de log de boot du noyau.
+- Le fichier `.config`.
+
+## VI. Assignment 01
+
+### À faire
+
+Créer un module noyau « Hello World » avec le comportement suivant. Bloc recopié :
+
+```text
+% sudo insmod main.ko
+% dmesg | tail -1
+[Wed May 13 12:59:18 2015] Hello world!
+% sudo rmmod main.ko
+% dmesg | tail -1
+[Wed May 13 12:59:24 2015] Cleaning up module.
+%
+```
+
+Le module doit compiler sur n’importe quel système. Le sujet signale que c’est un indice de compatibilité de version.
+
+### À rendre
+
+- Makefile et code source.
+
+Chaînes exactes : `Hello world!`, `Cleaning up module.`, fichier `main.ko`.
+
+## VII. Assignment 02
+
+### À faire
+
+- Prendre l’arbre Git du noyau de l’assignment 00 et modifier le Makefile pour changer le champ `EXTRAVERSION`. Après modification, reconstruction et reboot, la chaîne de version du noyau qui tourne doit contenir `-thor_kernel`.
+
+### À rendre
+
+- Log de boot du noyau.
+- Un patch du Makefile d’origine, selon les standards de soumission Linux (`Documentation/SubmittingPatches`).
+
+## VIII. Assignment 03
+
+Modifier le fichier C suivant pour qu’il respecte le style de code Linux (`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) :
+
+```c
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+
+int do_work(int *my_int, int retval) {
+        int x;
+        int y = *my_int;
+        int z;
+
+        for (x = 0; x < my_int; ++x)
+        {
+                udelay(10);
+        }
+
+        if (y < 10)
+                /* That was a long sleep, tell userspace about it */
+                pr_info("We slept a long time!");
+
+        z = x * y;
+        return z;
+            return 1;
+}
+
+int my_init(void)
+{
+        int x = 10;
+
+        x = do_work(&x, x);
+        return x;
+}
+
+void my_exit(void)
+{
+}
+
+module_init(my_init);
+module_exit(my_exit);
+```
+
+Chaîne exacte dans le code : `We slept a long time!`
+
+## IX. Assignment 04
+
+### À 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`.
+
+### À rendre
+
+- Un fichier de règles, adapté au système.
+- Le code mis à jour.
+- Une preuve que le module fonctionne comme prévu.
+
+Le sujet dit que ça a l’air simple et que c’est un peu piégeux. Indice : chapitre 14 du livre *Linux Device Drivers, 3rd Edition*, disponible gratuitement en ligne.
+
+## X. Assignment 05
+
+### À 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.
+- Le device misc est créé avec un numéro mineur dynamique. Pas de mineur statique réservé.
+- Implémenter `read` et `write`.
+- Le nœud doit apparaître dans `/dev/fortytwo`.
+- En lecture, le device retourne le login étudiant à l’appelant.
+- En écriture, les données sont comparées au login étudiant. Si ça correspond, l’écriture réussit. Sinon, une erreur « invalid value ».
+- Enregistrer le device misc au chargement du module, et le désenregistrer au déchargement.
+
+### À rendre
+
+- Le code mis à jour.
+- Une forme de preuve.
+
+Libellés exacts : `misc`, `/dev/fortytwo`, `invalid value`.
+
+## XI. Assignment 06
+
+### À 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.
+
+### À rendre
+
+- Le log de boot du noyau.
+
+Le sujet ne définit pas linux-next dans l’énoncé. C’est une partie du défi.
+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.
+
+## 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.)
+
+Cette tâche ressemble à l’assignment 05. L’interface cette fois est debugfs.
+
+Le sujet rapporte une rumeur : le créateur de debugfs aurait dit que la seule règle est « There are no rules. »
+
+La distribution doit monter debugfs sur `/sys/kernel/debug/`. Sinon, la monter avec la commande recopiée :
+
+```text
+mount -t debugfs none /sys/kernel/debug/
+```
+
+L’option `CONFIG_DEBUG_FS` doit être activée dans le noyau.
+
+### À faire
+
+- Modifier le module de l’assignment 01 pour créer un sous-répertoire debugfs nommé `fortytwo`.
+- Dans ce répertoire, trois fichiers virtuels : `id`, `jiffies` et `foo`.
+- `id` : même comportement que l’assignment 05. Lisible et inscriptible par tous les utilisateurs.
+- `jiffies` : lecture seule pour n’importe quel utilisateur. La lecture retourne la valeur courante du timer `jiffies` du noyau.
+- `foo` : inscriptible seulement par root, lisible par tout le monde. Les données écrites sont stockées, jusqu’à une page. La lecture retourne les données stockées. Verrouillage correct pour les lectures et écritures concurrentes.
+- Au déchargement du module, tous les fichiers debugfs sont nettoyés et la mémoire allouée est libérée.
+- Note du sujet : le répertoire debug doit être lisible globalement. Comme il n’y a pas d’option pour ça, utiliser `chown`.
+
+### À rendre
+
+- Le code.
+- Une preuve que le module fonctionne comme prévu.
+
+## XIII. Assignment 08
+
+Revenir au style de code.
+
+### À faire
+
+- Prendre le fichier suivant, corriger son style, et corriger son comportement.
+
+### À rendre
+
+- Le fichier C mis à jour et conforme au style.
+
+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 :
+
+```c
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/miscdevice.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+
+// Dont have a license, LOL
+MODULE_LICENSE("LICENSE");
+MODULE_AUTHOR("Louis Solofrizzo <louis@ne02ptzero.me>");
+MODULE_DESCRIPTION("Useless module");
+
+static ssize_t myfd_read
+(struct file *fp, char __user *user,
+size_t size, loff_t *offs);
+static ssize_t myfd_write(struct file *fp, const char __user *user,
+size_t size, loff_t *offs);
+
+static struct file_operations myfd_fops = {
+    .owner = THIS_MODULE, .read = &myfd_read, .write = &myfd_write
+};
+
+static struct miscdevice myfd_device = {
+    .minor = MISC_DYNAMIC_MINOR,.name = "reverse",
+    .fops = &myfd_fops };
+
+char str[PAGE_SIZE];
+char *tmp;
+
+static int __init myfd_init
+        (void) {
+    int retval;
+
+    retval = misc_register(&(*(&(myfd_device))));
+    return 1;
+}
+
+static void __exit myfd_cleanup
+    (void) {
+}
+
+ssize_t myfd_read
+        (struct file *fp,
+        char __user *user,
+        size_t size,
+        loff_t *offs)
+{
+        size_t t, i;
+        char *tmp2;
+
+/***************
+ * Malloc like a boss
+ ***************/
+        tmp2 = kmalloc(sizeof(char) * PAGE_SIZE * 2, GFP_KERNEL);
+        tmp = tmp2;
+        for (t = strlen(str) - 1, i = 0; t >= 0; t--, i++) {
+            tmp[i] = str[t];
+        }
+        tmp[i] = 0x0;
+        return simple_read_from_buffer(user, size, offs, tmp, i);
+}
+
+ssize_t myfd_write
+        (struct file *fp,
+        const char __user *user,
+        size_t size,
+        loff_t *offs) {
+    ssize_t res;
+
+    res = 0;
+    res = simple_write_to_buffer(str, size, offs, user, size) + 1;
+    // 0x0 = '\0'
+    str[size + 1] = 0x0;
+    return res;
+}
+
+module_init(myfd_init);
+module_exit(myfd_cleanup);
+```
+
+Libellés dans le code, à ne pas « corriger » avant d’avoir lu la capture : `LICENSE`, `Useless module`, `reverse`, `Dont have a license, LOL`, `Malloc like a boss`.
+
+Le nom du device dans ce fichier est `reverse`, pas `fortytwo`.
+
+## XIV. Assignment 09
+
+### À faire
+
+- Créer un module qui liste les points de montage du système, avec le nom associé.
+- Le fichier doit s’appeler `/proc/mymounts`.
+
+Exemple recopié :
+
+```text
+$> cat /proc/mymounts
+root       /
+sys        /sys
+proc       /proc
+run        /run
+dev        /dev
+```
+
+### À rendre
+
+- 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.
+
+## XV. Rendu et évaluation par les pairs
+
+Rendre le projet dans le dépôt Git, comme d’habitude.
+Seul le contenu du dépôt est pris en compte pendant l’évaluation.
+Vérifier les noms de dossiers et de fichiers.
+
+---
+
+## Grille de lecture
+
+### Obligatoire
+
+Tout se fait sur la distribution personnalisée (celle de ft_linux).
+
+| Exercice | Travail | Rendu |
+|----------|---------|--------|
+| 00 | Arbre Git de Linus, build, install, boot. `CONFIG_LOCALVERSION_AUTO=y` | log de boot, `.config` |
+| 01 | Module `main.ko`, messages `Hello world!` et `Cleaning up module.` Compile sur n’importe quel système | Makefile, sources |
+| 02 | `EXTRAVERSION` tel que la version qui tourne contient `-thor_kernel` | log de boot, patch au format `Documentation/SubmittingPatches` |
+| 03 | Mettre le fichier C au style `Documentation/CodingStyle` | fichier C |
+| 04 | Chargement auto du module au branchement d’un clavier USB, via l’outil hotplug de la distro | fichier de règles, code, preuve |
+| 05 | Device misc `/dev/fortytwo`, mineur dynamique, read = login, write = login ou erreur `invalid value` | code, preuve |
+| 06 | Dernier linux-next, build et boot | log de boot |
+| 07 | debugfs `fortytwo` avec `id`, `jiffies`, `foo`. `CONFIG_DEBUG_FS`. Montage `/sys/kernel/debug/` | code, preuve |
+| 08 | Style et comportement du fichier `reverse` | fichier C |
+| 09 | `/proc/mymounts` | sources, Makefile |
+
+### Bonus
+
+Le PDF n’a pas de chapitre bonus.
+
+### Interdit, ou hors du rendu
+
+- Faire le projet ailleurs que sur la distribution personnalisée.
+- Rendre autre chose que ce qui est dans le dépôt Git.
+- Pour 00, 02 et 06, le rendu demandé est une preuve (log, config, patch), pas seulement du code.
+- Inventer le comportement de l’assignment 08 : le sujet le laisse à découvrir.
+
+### Ce que la distro doit déjà savoir faire pour que ces exercices soient possibles
+
+Ces points ne sont pas une liste de paquets de ft_linux. Ce sont les besoins écrits dans Little Penguin :
+
+- Git, et un moyen de récupérer git.kernel.org puis linux-next.
+- Compiler, installer et booter un noyau qui n’est pas celui livré avec la distro.
+- Charger et décharger des modules (`insmod`, `rmmod`, `dmesg`).
+- Un mécanisme de hotplug parmi `depmod`, `kmod`, `udev`, `mdev`, `systemd`.
+- USB, au moins pour un clavier.
+- debugfs compilé et montable, `/proc`, `/dev`, `/sys`.
+- `sudo` apparaît dans l’exemple de l’assignment 01.