Ladebeze66/ft_linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

corectionsujets2

Browse Source
This commit is contained in:
Ladebeze66
2026-10-23 11:04:00 +02:00
parent 48728bb4bd
commit ca77961912
10 changed files with 100 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
docs/sujets/kfs-2.md
View File

@@ -4,15 +4,20 @@ 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) |
| PDF | [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.
![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. Pas de schéma de GDT dans ce PDF.
![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 fig. C3, plus bas, est la seule image légendée.
## Liens
@@ -56,13 +61,13 @@ 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. »
Tu as compris ? Bien. On avance. Le PDF écrit : « Get it ? Good. Now, let’s move on. »
## III. Objectifs
Créer, remplir et lier une Global Descriptor Table dans le noyau.
« Yup, that’s it. Not so much, eh ? »
Ouais, c’est tout. Pas grand-chose, hein ? Le PDF écrit : « 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.
@@ -70,23 +75,35 @@ Oui, le BIOS. Grâce à GRUB, il aidera beaucoup. Heureusement qu’il est déj
## IV. Instructions générales
Même cadre que KFS-1, avec quelques formulations différentes.
### IV.1 Code et exécution
### IV.1.1 Émulation
#### IV.1.1 Émulation
Partie non obligatoire. N’importe quel gestionnaire de virtuel convient. KVM est suggéré. Les exemples du sujet utilisent KVM.
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 ci-dessous utilisent KVM.
### IV.1.2 Langage
#### 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.
Le C n’est pas obligatoire. On peut utiliser n’importe quel langage pour cette suite de projets.
Tous les langages ne sont pas adaptés à un noyau. On pourrait coder un noyau en Javascript, mais est-ce une bonne idée ?
Beaucoup de documentations sont en C. Choisir un autre langage implique de traduire le code tout du long.
Image [C3](captures/03-kfs-choose-wisely.png) au même endroit que dans KFS-1.
Toutes les fonctionnalités d’un langage ne sont pas utilisables dans un noyau basique. Exemple avec le C++ : ce langage utilise `new` pour l’allocation, les classes et les déclarations de structures. Dans ce noyau, il n’y a pas encore d’interface mémoire, donc ces fonctionnalités sont inutilisables pour l’instant.
Beaucoup de langages peuvent remplacer le C : C++, Rust, Go, etc. On peut même coder le noyau entier en ASM.
![Chevalier du Graal, texte YOU MUST CHOOSE... BUT CHOOSE WISELY.](captures/03-kfs-choose-wisely.png)
**Fig. C3 — section Langage.** Même image que dans KFS-1. Texte dans l’image : « YOU MUST CHOOSE... » puis « BUT CHOOSE WISELY. » Interprétation : elle illustre le choix du langage. Pas un schéma de GDT ni de pile. Crédit « quickmeme.com » en bas à droite.
### IV.2 Compilation
Compilateur libre. L’auteur utilise gcc et nasm. Un Makefile doit être ajouté au dépôt.
#### IV.2.1 Compilateurs
Mêmes flags, présentés comme un exemple C++ :
N’importe quel compilateur. L’auteur utilise personnellement gcc et nasm. Un Makefile doit être ajouté au dépôt.
#### IV.2.2 Flags
Pour booter sans dépendance, compiler avec les flags suivants. Les adapter au langage. Ceux-ci sont un exemple pour le C++ :
- `-fno-builtin`
- `-fno-exception`
@@ -95,23 +112,24 @@ Mêmes flags, présentés comme un exemple C++ :
- `-nostdlib`
- `-nodefaultlibs`
Pas de lien vers une bibliothèque de l’hôte, sinon le noyau ne s’exécute pas.
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.
### 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.)
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 ce noyau.
Attention : on CAN utiliser le binaire `ld` disponible sur l’hôte, mais il est FORBIDDEN d’utiliser le fichier `.ld` de l’hôte. KFS-1 écrivait CANNOT à cet endroit. KFS-2 écrit FORBIDDEN.
### IV.4 Architecture
i386 (x86) obligatoire.
L’architecture i386 (x86) est obligatoire (on pourra remercier l’auteur plus tard).
### IV.5 Documentation
Le wiki OSDev est recommandé par l’auteur. Lien sur le mot `OSDev`.
Il existe beaucoup de documentation, bonne et mauvaise. L’auteur estime que le wiki OSDev est l’un des meilleurs. Le mot `OSDev` pointe vers <http://wiki.osdev.org/Main_Page>.
### IV.6 Code de base
Il faut prendre le code KFS précédent et travailler à partir de lui.
Pour ce sujet, 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
@@ -139,13 +157,13 @@ 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 ! »
Amuse-toi. Le PDF écrit : « Have fun ! »
Encadré PERFECT, identique à KFS-1 : bonus évalué seulement si l’obligatoire est intégralement fonctionnel.
Encadré : le bonus n’est évalué que si la partie obligatoire est PERFECT. Perfect veut dire que l’obligatoire a été fait intégralement et fonctionne sans dysfonctionnement. Si tous les prérequis obligatoires ne sont pas validés, le bonus n’est pas évalué du tout.
## 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 travail dans le dépôt Git, comme d’habitude. Seul le travail à l’intérieur du dépôt est évalué pendant la soutenance. Ne pas hésiter à revérifier les noms des dossiers et des fichiers.
Rendre le code, un Makefile et une image virtuelle basique pour le noyau.
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.