Peut-on utiliser la stdio lors du codage d’un kernel…?

J’ai besoin de construire un système d’exploitation, très petit et basique, avec le moins de fonctionnalités, codé en C.

C’est probablement un système d’exploitation CUI qui gère un peu la mémoire et qui possède au moins un éditeur de texte et une calculasortingce. Il s’agit simplement d’une expérimentation sur la création d’un code permettant un contrôle total et direct de votre matériel.

Néanmoins, je vais avoir besoin d’une interface qui aura besoin de fonctions d’entrée / sortie comme printf (& args), scanf (& args). Maintenant, ma question fondamentale est la suivante: dois-je utiliser les en-têtes existants ou procéder à un codage à partir de rien et pourquoi?

Je serais plus que très reconnaissant envers vous pour votre aide.

Premièrement, vous ne pouvez pas créer de lien avec quoi que ce soit depuis libc … vous allez devoir tout coder à partir de zéro.

Ayant moi-même travaillé sur un micro-kernel, je n’utiliserais pas les en-têtes stdio fournis avec libc car ils vont être encombrés de nombreuses informations supplémentaires qui seront soit non pertinentes pour votre système d’exploitation, soit provoqueront des erreurs de compilation. manque de définitions, etc. Ce que je ferais cependant, c’est de garder les signatures de fonction pour ces fonctions standard identiques … afin d’avoir un fichier appelé stdio.h pour votre système d’exploitation, mais ce serait une solution très réduite fichier d’en-tête avec les exigences minimales de base pour vos besoins, et ne disposant que des fonctions d’E / S standard dont vous avez besoin, avec les signatures standard correctes.

Gardez à l’esprit sur le back-end, c’est-à-dire que dans votre fichier stdio.c , vous devrez pointer ces fonctions sur un pilote de console personnalisé ou sur un autre type de lecteur de caractères pour votre affichage. Soit ça, soit vous pouvez simplement les utiliser comme wrappers pour d’autres routines d’impression d’affichage au niveau du kernel. Vous allez également vouloir vous assurer que, même si vous pouvez utiliser une directive #include dans vos autres modules de code de système d’exploitation pour accéder à ces fonctions d’impression, vous ne libc pas de lien avec libc . Cela peut être fait en utilisant gcc -ffreestanding .

Il suffit de recibler newlib.

printf, scanf, etc. s’appuient sur des fonctions spécifiques à l’implémentation pour obtenir un seul caractère ou imprimer un seul caractère. Vous pouvez ensuite faire votre stdin et stdout l’UART 1 par exemple.

Le kernel lui-même n’aurait pas besoin des fonctions printf et scanf , si vous ne voulez pas le garder en mode kernel et utiliser les applications que vous avez planifiées. Mais pour les fonctions de base de printf et scanf, vous pouvez écrire vos propres fonctions printf et scanf, qui fourniraient un support de base pour l’impression et la saisie. Je n’ai pas beaucoup d’expérience à ce sujet, mais vous pouvez essayer de créer une mémoire tampon de console, où le pilote de clavier place la lecture en caractères ASCII (après conversion en codes de balayage), puis fait fonctionner les fonctions printf et scanf . J’ai une implémentation de base où j’ai écrit un gets au lieu de scanf et j’ai gardé les choses simples. Pour obtenir un résultat entier, vous pouvez écrire une fonction atoi pour convertir la chaîne en nombre.

Pour porter dans d’autres bibliothèques, vous devez créer les composants dont dépendent les bibliothèques. Vous devez prendre la décision si vous pouvez coder dans le support du kernel afin que les bibliothèques puissent être imscopes. S’il est plus difficile que de coder certaines fonctions de sortie en entrée de base, je pense que ce ne sera pas si mal à ce stade,