LetsGo OS
1.0.0
C'est une petite expérience sur laquelle je travaille où j'essaie de créer un noyau OS dans le langage de programmation Go.
L'objectif n'est pas de créer un système d'exploitation fonctionnel "entièrement" (quoi que cela signifie) mais en savoir plus sur les systèmes d'exploitation et comment ils sont fabriqués.
À l'origine, j'avais prévu de mettre en œuvre un système FAT32-FileSystème. J'en ai mis en œuvre une fois (en c) mais je ne peux pas continuer à travailler sur Project en raison de Harware manquant. Bien sûr, vous pouvez facilement implémenter un système de fichiers dans Linux, mais c'est un peu ennuyeux.
Au lieu de cela, j'ai commencé à écrire mon propre système d'exploitation pour ce projet. C'est aussi une façon de commencer à apprendre Go. Eh bien, au moins un peu.
Quand j'ai eu l'idée d'écrire un système d'exploitation, je savais que je ne voulais pas utiliser C, car j'avais déjà une certaine expérience de la rédaction d'un système d'exploitation dans C. J'ai délibéré si je devais utiliser la rouille ou aller pour écrire mon système d'exploitation. Le facteur décisif à la fin était que GO serait le plus grand défi.
Maintenant, vous pourriez penser que ce n'est pas si bon d'une idée d'utiliser GO pour écrire un noyau, et vous auriez raison. Le go-runtime est conçu pour être utilisé dans l'espace utilisateur d'un système d'exploitation. Il existe de nombreuses hypothèses que cela implique, comme la capacité d'invoquer des systèmes et l'utilisation de l'allocation de mémoire dynamique. Dans un noyau, vous ne pouvez pas compter sur un système d'exploitation pour gérer cela pour vous, car vous êtes le système d'exploitation. Cependant, avec une programmation minutieuse et une abandon de certaines fonctionnalités de Go, vous pouvez le faire, alors pourquoi pas? C'est un défi.
L'un des objectifs de ce projet est de réaliser rapidement des choses, donc je n'ai pas passé de temps à concevoir le système d'exploitation. Pour accélérer l'ensemble du processus, j'ai décidé d'utiliser l'interface syscall de Linux. De cette façon, je n'aurais pas à écrire mes propres bibliothèques d'espace utilisateur et je pourrais utiliser n'importe quel langage de programmation que je voulais dans mon espace utilisateur. Il a cependant pas mal d'inconvénients. Bien que je fasse les systèmes de la même manière que Linux, cela m'oblige également à utiliser toutes les hypothèses de Linux. Par exemple, le démarrage d'un processus me demande pour configurer son espace mémoire de la même manière que Linux, les systèmes doivent retourner des valeurs attendues sur un noyau Linux et la conception du noyau est supposée monolithique.
Je ne sais pas encore si je m'en tiens à ce design. Une autre idée que j'ai eue est d'écrire mon propre ABI mais aussi d'écrire une bibliothèque de wrapper Linux-Syscall qui intercepterait les systèmes Linux et le traduirait dans mon système d'exploitation.
