Get best of the week

Système d'exploitation Sivelkiriya: technologies

Bonjour, Habr.

Cet article poursuit la série de publications sur le projet du système d'exploitation Sivelkiriya. Comme déjà mentionné dans les articles précédents, cet OS est actuellement à un stade précoce de conception et de développement, donc ceux qui veulent obtenir des preuves devront être patients. Au cas où, je mentionnerai une fois de plus que l’auteur n’a pas l’intention de convaincre qui que ce soit de quoi que ce soit, mais plutôt de continuer à publier afin de bénéficier des discussions. Je profite de cette occasion pour exprimer ma gratitude à tous ceux qui ont laissé des commentaires utiles dans les publications antérieures.

Le premier article du cycle a fourni de brèves informations sur la structure de ce système d'exploitation. Dans le deuxième articleles objectifs du projet ont été décrits, ainsi que la façon dont il était censé sortir du cercle vicieux «pas de logiciel - pas d'utilisateurs - pas de développeurs - pas de logiciel». Cette fois, l'accent sera mis sur les problèmes architecturaux. Il sera montré par quels moyens techniques il est censé assurer l'interaction de modules écrits par différentes personnes dans différentes langues et assemblés sous différents environnements. De plus, de petits détails de l'architecture seront affectés.

Interprètes de module


Pour assurer le chargement, le démarrage et l'exécution des modules, le concept d'interprètes est introduit à Sivelkiriya. Les interprètes eux-mêmes sont des modules et, par rapport aux modules qu'ils exécutent, assument les responsabilités suivantes:

  1. Téléchargement des modules utilisés dans la RAM, initialisation, finalisation et déchargement;
  2. Relier l'API fournie par le système d'exploitation au code exécutable des modules: assurer le passage des appels et des données de l'API du système d'exploitation au code des modules et inversement;
  3. Téléchargez et préparez l'environnement d'exécution requis par le module;
  4. Traduction du code du module à partir de toute représentation intermédiaire (code source dans un langage interprété; code d'octet; langage intermédiaire; assemblage destiné à une autre plate-forme) en une séquence d'instructions machine. Les actions spécifiques à cette étape (interprétation de script, interprétation de bytecode, compilation JIT, émulation, etc.) sont déterminées par la méthode de livraison du module;
  5. Cacher le fonctionnement du module au système d'exploitation et aux autres modules.

De plus, l'exécuteur peut assumer la tâche d'isoler les données de divers modules si la coexistence de deux modules ou plus dans le même espace d'adressage ne pose pas de risque pour la sécurité (par exemple, pour le code managé), et le travail de l'exécuteur lui-même est si stable qu'il y a des erreurs dans le chargement Ce module ne conduira pas à des problèmes dans le travail de l'entrepreneur et d'autres modules servis par lui.

Ce concept permet d'utiliser différentes méthodes pour assembler des modules dans un système commun. Par exemple, le code machine obtenu en compilant du code C ++ sera chargé par un exécuteur prenant en charge l'exécution directe dans un espace d'adressage séparé et lié à l'environnement d'exécution nécessaire. Le code IL géré peut être chargé par un exécuteur prenant en charge l'exécution du code géré, de plus, l'isolement peut être effectué à la fois au niveau du système d'exploitation (en chargeant divers modules dans différents espaces d'adressage) et au niveau de l'exécuteur (en chargeant divers modules dans un espace d'adressage commun, mais dans différents domaines de l'environnement).

Une exception est le cas de l'exécution du code machine sous Sivelkiriya, qui est exécuté dans le cadre du système d'exploitation principal sous la forme d'un ensemble de bibliothèques et / ou de processus. L'exécution directe du code machine dans ces conditions n'est autorisée que si elle garantit l'absence d'appels du code machine vers le système d'exploitation principal en contournant Sivelkiriya, ou si de tels appels sont nécessaires du point de vue du système. Par exemple, cette condition peut être remplie dans un environnement d'entreprise contrôlé, ainsi que pour des projets open source. D'autre part, les modules qui accèdent aux ressources du système d'exploitation principal, par définition, ont besoin d'un moyen d'appeler ses fonctions. Si la "propreté" du code machine ne peut être garantie, un tel code peut être exécuté en mode émulation (ainsi que du code compilé pour une autre plateforme).

Si Sivelkiriya est lancé comme système d'exploitation principal, la séparation des espaces d'adressage au niveau du système d'exploitation est effectuée par son noyau. S'il est exécuté comme un ensemble de bibliothèques ou de processus sous le système d'exploitation principal, pour garantir l'isolation, différents modules peuvent être chargés dans différents processus du système d'exploitation principal. Les modules système qui sont responsables du travail direct avec l'équipement (par exemple, les pilotes de système de fichiers), en cas de démarrage sous le système d'exploitation principal, seront remplacés par des modules qui émulent ce comportement, masquant ainsi les différences avec les modules d'application.

L'environnement d'exécution susmentionné, spécifique à un langage et à un compilateur spécifiques, est la première de deux exceptions à la règle exigeant l'échange de données entre tous les modules uniquement via les interfaces d'objet du système, car le chargement dans l'espace d'adressage du module est nécessaire à son fonctionnement. Le concept de bibliothèques liées dynamiquement utilisées par plusieurs modules n'est généralement pas pris en charge dans Sivelkiriya, car il vise à implémenter le partage de code, qui est déjà implémenté via des interfaces de module.

La deuxième exception est l'autorisation d'utiliser des bibliothèques liées dynamiquement à plusieurs modules qui sont livrés ensemble dans le même package. Dans le même temps, Sivelkiriya ne fournit pas la possibilité de connecter la même bibliothèque à d'autres modules, ainsi qu'aux sous-systèmes de recherche de bibliothèques dynamiques.

Lorsque le système démarre, une partie des artistes est chargée en mémoire en même temps que le noyau, afin d'éviter la situation où un autre artiste est nécessaire pour charger l'artiste, qui n'est pas non plus encore chargé. Cela s'applique tout d'abord aux exécuteurs exécutant le lancement du code machine sur cette plateforme. Les autres artistes sont chargés en mémoire selon les règles générales.

Autres solutions architecturales


Ce qui suit est une brève liste non structurée de principes secondaires pour la construction de l'architecture Sivelkiriya OS. Ils ne sont pas aussi importants que les principes de base décrits ci-dessus, mais méritent néanmoins d'être mentionnés.

  1. , «». , , , . -, . . , , , , , , . , ; , , Bluetooth, WiFi , Bluetooth, . , (, , , ).
  2. , . , « » « ».
  3. , . , « » « » «». , , .
  4. . , « » ( , , , ), « » . , « », « », ( ) . .
  5. , , , . , , , , . - , , .
  6. ( . .) . , , , - . .
  7. ( ) , «», , , . , , , , .
  8. , , . ( , . .) . . , , .
  9. . , , . — , , , . . , : , ( ) , , .
  10. , : . , .
  11. , , , , — . « » , ( ). , . .
  12. : , , . , , . , , , .
  13. , : , , , , , , , , , . : , , SSD, — RAID- , — , . .
  14. . ( ). , , (, , ), ( ), , , WYSIWYG- , . , .
  15. : , , . , , , ( ). , , , . , , , ( , . .).
  16. , , . , « » , (, 1 ) . , , , : , (, ) , , , , , .
  17. , , (, , ). , — , , , . — (, . .): , , , , . , . , , ( «» ). , . (, ) , ( , . .). , , . , ( , , . .) , .


La première publication du cycle est disponible ici . Le second est ici . Le quatrième est ici . Le texte intégral de l'article est disponible sur le site web du projet .

More articles:


All Articles