ft_linux/docs/sujets/README.md

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	originaux/ft_linux_subject.pdf
2	Little Penguin 1.1	little-penguin.md	originaux/little_penguin_subject.pdf
3	KFS-1 v1	kfs-1.md	originaux/kfs-1_subject.pdf
4	KFS-2 v2	kfs-2.md	originaux/kfs-2_subject.pdf

Images : captures/README.md.

Le cadrage ft_linux proposé avant cette lecture est figé dans ../notes/cadrage-ft-linux-en-attente.md. Il n’est pas lancé. Les questions pour le binôme sont dans ../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.