comme c’est normal.
1) Comment débogueriez-vous le noyau pendant la phase de développement ?
Cela dépend à la fois de la machine et de l’état d’avancement du noyau : sur les systèmes plus simples, c’est généralement plus facile à mettre en place. Voici ce que j’ai dû faire sur un 386 en mode protégé.
Le pire c’est de commencer : une fois que vous avez un système minimal, vous pouvez utiliser printf etc, mais passer en mode protégé sur un 386 n’est pas drôle, surtout si au début vous ne connaissez pas très bien l’architecture. Il est terriblement facile de redémarrer le système à ce stade : si sur le 386 quelque chose ne va pas, il s’éteint et redémarre - vous n’avez même pas une chance de voir ce qui ne va pas.
Printf() n’est pas très utile - un redémarrage efface également l’écran et, de toute façon, vous devez avoir accès à la mémoire vidéo, qui peut échouer si vos segments sont incorrects, etc. Ne pensez même pas aux débogueurs : aucun des débogueurs que je connais n’est capable de suivre l’évolution d’un 386 en mode protégé. Un émulateur de 386 pourrait faire l’affaire, ou un matériel lourd, mais ce n’est généralement pas réalisable.
Ce que j’ai utilisé est une simple boucle d’exécution : j’ai mis des instructions comme
die :
jmp die
à des endroits stratégiques. S’il se bloquait, c’était bon, s’il redémarrait, c’était bon. vous saviez qu’au moins ça s’était passé avant le die-loop. Alternativement, vous pourriez utiliser les ports io pour des indices sonores, mais comme je n’avais pas d’expérience avec le matériel PC, je n’ai même pas utilisé ça. Je ne dis pas que c’est la seule façon : je n’ai pas commencé à écrire un noyau, j’ai juste voulu explorer les primitives de commutation de tâches du 386, etc, et c’est ainsi que j’ai commencé (en environ en avril 1991).
Une fois que vous avez mis en place un système minimal et que vous pouvez utiliser l’écran pour la sortie, ça devient un peu plus facile, mais c’est à ce moment-là que vous devez activer les interruptions. Bang, redémarrage instantané, et retour à l’ancienne méthode. En tout et pour tout, il m’a fallu environ 2 mois pour que j’arrive à régler tous les problèmes liés au 386. Ainsi je n’avais plus à compter sur le fait d’éviter de redémarrer en même temps, et d’avoir les les choses de base (paging, timer-interrupt et un simple commutateur de tâches pour tester les segments, etc).
2) Pouvez-vous tester la fonctionnalité du noyau en l’exécutant en tant que processus sur un autre système d’exploitation ? Le système d’exploitation (l’environnement de développement) ne génèrerait-il pas des exceptions dans les cas où le noyau (du nouvel OS) essaie de modifier les registres "privilégiés" ?
Oui, c’est généralement possible pour certaines choses, mais par exemple les pilotes de périphériques doivent généralement être testés sur la machine nue. J’ai utilisé minix pour pour développer linux, je n’avais donc pas accès aux registres d’E/S, aux interruptions, etc. Sous DOS, il aurait été possible d’avoir accès à tout cela, mais il n’y a pas le mode 32 bits. Intel n’est pas si génial que ça - cela aurait été probablement beaucoup plus facile sur un 68040 ou similaire.
Donc, après avoir obtenu un simple commutateur de tâches (il a commuté entre deux processus qui ont imprimé AAAA… et BBBB… respectivement en utilisant la fonction de timer-interrupt - Dieu que j’étais fier de ça), je devais continuer à déboguer en utilisant printf. La première chose écrite a été le pilote de clavier : c’est la raison pour laquelle il est toujours écrit complètement en assembleur (je n’ai pas encore osé passer au C - je déboguais encore au niveau des instructions).
Après cela, j’ai écrit les pilotes de série, et voilà, j’avais un programme de terminal simple qui fonctionnait (enfin, pas en tant que tel). programme de terminal fonctionnant (enfin, pas si simple que ça en fait). C’était toujours les deux mêmes processus (AAA..), mais maintenant ils lisaient et écrivaient sur les lignes sur la console/série les lignes à la place. J’ai du rebooter pour me sortir de tout ça, mais c’était un noyau simple.
Après cela, c’était la navigation à voile : le codage est encore difficile, mais j’ai eu
