# KFS_1 — Grub, boot and screen Traduction française du sujet. Le PDF reste la source en cas de doute. | | | |--|--| | PDF | [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 ! | ![Marque 42 : bande verticale de triangles gris sur fond noir](captures/01-couverture-42.png) **Fig. C1 — page de titre.** Aucun texte dans l’image. Interprétation : habillage 42, pas une consigne. ![Filigrane géométrique gris pâle](captures/02-habillage-page.png) **Fig. C2 — pages intérieures.** Aucun texte. Interprétation : filigrane répété. La seule image qui porte une légende est la fig. C3, dans la section langage. ## Liens | Ancre | Cible | |-------|--------| | `pedago@42.fr` | mailto | | `OSDev` (phrase « the OSDev wiki is one of the best ») | | | `here` (phrase « Some docs here. ») | | --- ## I. Introduction Bienvenue dans le premier projet Kernel from Scratch. 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 à partir de rien (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 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. 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 En fait, ce n’est pas tant de code que ça. Ce sujet est une introduction au développement noyau. Quelqu’un doit bien apprendre. Le PDF écrit : « A (wo)man must learn. » ## 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. ![Chevalier du Graal, texte YOU MUST CHOOSE... BUT CHOOSE WISELY.](captures/03-kfs-choose-wisely.png) **Fig. C3 — fin de III.1.2 Langage, page 4 du PDF.** Texte dans l’image, en deux lignes : « YOU MUST CHOOSE... » puis « BUT CHOOSE WISELY. » Interprétation : le personnage (le chevalier du Graal) répète la dernière phrase de la section, sur le choix du langage. Ce n’est pas un schéma d’architecture. Un crédit « quickmeme.com » est visible en bas à droite de l’image. ### 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 (on pourra remercier l’auteur plus tard). ### 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 . ## 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 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). ## 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 facilement de l’un à l’autre. Le PDF écrit « between then ». 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 PDF écrit `Carefull`) : le noyau n’en fait encore rien, inutile qu’elle ait la taille d’un éléphant. 10 MB est la borne supérieure. À toi de faire avec. Le PDF écrit : « deal with it. » --- ## 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`.