Serena
1.0.0
Serena est un système d'exploitation expérimental basé sur des principes de conception modernes avec le support pour une concurrence préemptive omniprésente et plusieurs utilisateurs. Le noyau est orienté objet et conçu pour être multiplateforme et une preuve future. Il fonctionne sur des systèmes AMIGA avec un CPU 68030 ou un meilleur CPU.
Un aspect qui le distingue des OSS basés sur le filetage traditionnel est qu'il est purement construit autour des files d'attente de répartition quelque peu similaires à la grande répartition d'Apple Central. Il n'y a pas de prise en charge de la création de threads dans l'espace utilisateur ni dans l'espace du noyau. Au lieu de cela, le noyau implémente un concept de processeur virtuel où il gère dynamiquement un pool de processeurs virtuels. La taille du pool est automatiquement ajustée en fonction des besoins des files d'attente de répartition et des processeurs virtuels sont affectés aux processus au besoin. Toute la concurrence du noyau et de l'espace utilisateur est obtenue en créant des files d'attente de répartition et en soumettant des éléments de travail aux files d'attente de répartition. Les éléments de travail sont simplement des fermetures (une fonction avec un état associé) à partir du point de vue de l'utilisateur.
Un autre aspect intéressant est la manipulation d'interruption. Le code qui souhaite réagir à une interruption peut enregistrer un sémaphore de comptage avec le contrôleur d'interruption pour l'interruption qu'il souhaite gérer. Le contrôleur d'interruption signalera ensuite le sémaphore chaque fois que l'interruption se produit. L'utilisation d'un sémaphore de comptage garantit que le code qui s'intéresse à l'interruption ne manque pas l'occurrence d'une interruption. L'avantage de traduire les interruptions en signaux sur un sémaphore est que le code de traitement des interruptions s'exécute dans un contexte bien défini qui est le même type de contexte que tout autre type de code. Les informations selon lesquelles une interruption se sont produites ne sont jamais perdues, que le code du gestionnaire d'interruption soit occupé avec d'autres choses au moment de l'interruption ou non.
Le noyau est généralement réentrant. Cela signifie que les processeurs virtuels continuent d'être planifiés et que le contexte commuté de manière préventive même si le CPU s'exécute à l'intérieur du noyau. De plus, un compliment complet de comptage des sémaphores, des variables de condition et des API de verrouillage sont disponibles à l'intérieur du noyau. L'API de ces objets ressemble étroitement à ce que vous trouverez dans une implémentation d'espace utilisateur d'un système d'exploitation traditionnel.
Serena implémente une structure de processus hiérarchique similaire à POSIX. Un processus peut engendrer un certain nombre de processus enfants et il peut transmettre une ligne de commande et des variables d'environnement à ses enfants. Un processus accède aux ressources d'E / S via des canaux d'E / S qui sont similaires aux descripteurs de fichiers dans POSIX.
Il existe cependant deux différences notables entre le modèle de processus de style POSIX et le modèle Serena: d'abord au lieu d'utiliser Fork () suivi par Exec () pour engendrer un nouveau processus, vous utilisez une seule fonction dans Serena appelée process_spawn (). Cela rend le frai un processus beaucoup plus rapide et beaucoup moins sujet aux erreurs.
Deuxièmement, un processus enfant n'hérite pas par défaut les descripteurs de fichiers de son parent. La seule exception est les descripteurs de fichiers 0, 1 et 2 qui représentent les flux d'entrée et de sortie du terminal. Ce modèle est beaucoup moins sujet aux erreurs par rapport au modèle POSIX où un processus doit faire attention à fermer les descripteurs de fichiers qu'il ne veut pas transmettre à un processus d'enfant avant qu'il ne fasse un enfant. Faire cela a été facile dans les premiers jours d'Unix lorsque les applications étaient à peu près autonomes et lorsqu'il n'y avait pas de support pour les bibliothèques dynamiques. C'est le contraire aujourd'hui car les applications sont beaucoup plus complexes et dépendent de nombreuses bibliothèques tierces.
Le format de fichier exécutable à l'heure actuelle est le format de fichier ATARI ST GEMDOS qui est proche par rapport au format exécutable AOT. Ce format de fichier sera finalement remplacé par un format de fichier qui pourra prendre en charge les bibliothèques dynamiques. Cependant, pour l'instant, il est assez bon pour faire le travail.
Le noyau implémente Serenafs qui est un système de fichiers hiérarchique avec des autorisations et des informations utilisateur et de groupe. Un système de fichiers peut être monté au-dessus d'un répertoire situé dans un autre système de fichiers pour étendre l'espace de noms de fichiers. Tout cela fonctionne de manière similaire à son fonctionnement dans les systèmes POSIX. Un processus qui souhaite engendrer un processus enfant peut spécifier que le processus enfant doit être confiné à un sous-arbre de l'espace de noms de système de fichiers global.
Le système de fichiers de démarrage est actuellement basé sur RAM. La ROM contient une image de disque qui est créée avec l'outil de disque et qui sert de modèle pour le disque RAM. Cette image de disque ROM est copiée dans RAM à l'heure du démarrage.
L'espace utilisateur prend en charge LIBC, LIBSYSTEM, LIBCLAP et les tout début de LIBM. Libsystem est une bibliothèque qui implémente le côté espace utilisateur de l'interface du noyau. LibClap est une bibliothèque qui met en œuvre un analyse d'argument pour les programmes d'interface de ligne de commande.
Serena OS est livrée avec un shell qui implémente une langue de coquille officiellement définie. Vous pouvez trouver le document Shell ici.
Les services de noyau suivants sont mis en œuvre pour le moment:
Les services d'espace utilisateur suivant sont disponibles pour le moment:
Les programmes d'espace utilisateur suivant sont disponibles pour le moment:
Le niveau d'exhaustivité et d'exactitude des différents modules varie un peu pour le moment. Les choses sont génériques pour s'améliorer avec le temps :)
Le matériel suivant est pris en charge pour le moment:
La mise en place du projet pour le développement et l'exécution du système d'exploitation est un peu impliqué. Les instructions ci-dessous sont pour Windows, mais elles devraient fonctionner à peu près la même chose sur Linux et MacOS.
La première chose dont vous aurez besoin est un émulateur d'ordinateur Amiga. J'utilise winuae que vous pouvez télécharger depuis https://www.winuae.net/download
Téléchargez le programme d'installation de Winuae et exécutez-le. Cela placera l'émulateur dans le répertoire «Program Files» sur votre lecteur de démarrage.
Téléchargez le prochain et installez le compilateur et l'assembleur VBCC nécessaires pour construire le système d'exploitation. Vous pouvez trouver que la page d'accueil du projet se trouve sur http://www.compilers.de/vbcc.html et la page de téléchargement des outils à http://sun.hasenbraten.de/vbcc.
La version que j'utilise pour mon développement et que je sais fonctionne correctement sur Windows 11 est de 0,9h. Assurez-vous d'ajouter une variable d'environnement avec le nom VBCC qui pointe vers le dossier VBCC sur votre disque et ajoutez le dossier vbccbin à la variable d'environnement PATH .
Notez que vous devez installer Microsoft Visual Studio et des outils de ligne de commande car le compilateur Microsoft C est nécessaire pour créer les outils de construction sur Windows.
Enfin, installez GNU pour faire des fenêtres et assurez-vous qu'elle est dans la variable d'environnement PATH . Une façon directe de procéder est en exécutant la commande WINGET suivante dans une fenêtre de shell: winget install GnuWin32.Make .
Il vous suffit d'exécuter cette étape une fois et avant d'essayer de construire le système d'exploitation. Le but de cette étape est de créer quelques outils nécessaires pour construire les bibliothèques du noyau et de l'espace utilisateur. Vous pouvez trouver une documentation pour ces outils ici.
Ouvrez d'abord une invite de commande de développeur dans Windows Terminal, puis CD dans le dossier Serena/Tools . Tapez make et appuyez sur Retour. Cela créera tous les outils requis et les placera dans un dossier Serena/build/tools . Les outils seront conservés à cet endroit même si vous effectuez un projet complet du projet de système d'exploitation.
Ouvrez le dossier du projet Serena dans le code Visual Studio et sélectionnez Build All dans le menu Run Build Task... Cela construira le noyau, Libsystem, Libc, Libm et Shell et générera un seul fichier Serena.rom à l'intérieur du Serena/product/Kernel/ Dossier. Ce fichier ROM contient le noyau, les bibliothèques d'espace utilisateur et le shell.
Vous devrez d'abord créer une configuration Amiga avec au moins un CPU 68030 (c'est-à-dire Amiga 3000 ou 4000) dans WinUae si vous ne l'avez pas déjà fait. La façon la plus simple de le faire est d'aller à Quickstart et de sélectionner A4000 comme modèle. Accédez ensuite à la page matériel / ROM et mettez à jour le champ de texte "Fichier ROM principal" de sorte qu'il pointe vers le fichier Serena.rom dans le dossier Serena/build/product/ Folder sur votre disque. Enfin, donnez à votre Amiga virtuel au moins 1 Mo de RAM rapide en accédant à la page matérielle / RAM et en définissant l'entrée "lente" sur 1 Mo. Enregistrez cette configuration afin que vous n'ayez pas à le recréer la prochaine fois que vous souhaitez exécuter le système d'exploitation.
Chargez la configuration, puis appuyez sur le bouton Démarrer ou double-cliquez simplement sur la configuration dans la page Configurations pour exécuter le système d'exploitation. L'émulateur doit ouvrir un écran qui affiche un message de démarrage puis une invite de shell. Voir la page Shell pour une liste de commandes prises en charge par le shell.
Distribué sous la licence du MIT. Voir LICENSE.txt pour plus d'informations.
Dietmar Planitzer - @linkedin
Lien du projet: https://github.com/dplanitzer/serena
