Get best of the week

Sivelkiriya Betriebssystem: Technologien

Hallo Habr.

Dieser Artikel setzt die Reihe von Veröffentlichungen über das Projekt des Betriebssystems Sivelkiriya fort. Wie bereits in früheren Artikeln erwähnt, befindet sich dieses Betriebssystem derzeit in einem frühen Stadium des Entwurfs und der Entwicklung. Daher müssen diejenigen, die Beweise erhalten möchten, geduldig sein. Für alle Fälle möchte ich noch einmal erwähnen, dass der Autor niemanden von irgendetwas überzeugen will, sondern weiterhin veröffentlicht, um von den Diskussionen zu profitieren. Ich nutze diese Gelegenheit, um allen meinen Dank auszudrücken, die in früheren Veröffentlichungen nützliche Kommentare hinterlassen haben.

Der erste Artikel des Zyklus enthielt kurze Informationen zur Struktur dieses Betriebssystems. Im zweiten ArtikelDie Ziele des Projekts wurden beschrieben und wie es aus dem Teufelskreis „keine Software - keine Benutzer - keine Entwickler - keine Software“ ausbrechen sollte. Dieses Mal liegt der Schwerpunkt auf architektonischen Fragen. Es wird gezeigt, mit welchen technischen Mitteln das Zusammenspiel von Modulen sichergestellt werden soll, die von verschiedenen Personen in verschiedenen Sprachen geschrieben und unter verschiedenen Umgebungen zusammengestellt wurden. Darüber hinaus sind kleine Details der Architektur betroffen.

Modul-Darsteller


Um das Laden, Starten und Ausführen von Modulen sicherzustellen, wird in Sivelkiriya das Konzept der Darsteller eingeführt. Die Darsteller selbst sind Module und übernehmen in Bezug auf die von ihnen ausgeführten Module folgende Aufgaben:

  1. Herunterladen gebrauchter Module in den Arbeitsspeicher, Initialisierung, Finalisierung und Entladung;
  2. Verknüpfen der vom Betriebssystem bereitgestellten API mit dem ausführbaren Code der Module: Sicherstellen, dass Aufrufe und Daten von der API des Betriebssystems an den Code der Module weitergeleitet werden und umgekehrt;
  3. Laden Sie die vom Modul benötigte Laufzeitumgebung herunter und bereiten Sie sie vor.
  4. Übersetzung des Modulcodes aus einer beliebigen Zwischendarstellung (Quellcode in einer interpretierten Sprache; Bytecode; Zwischensprache; Assemblierung für eine andere Plattform) in eine Folge von Maschinenanweisungen. Die spezifischen Aktionen in diesem Schritt (Skriptinterpretation, Bytecode-Interpretation, JIT-Kompilierung, Emulation usw.) werden durch die Modulbereitstellungsmethode bestimmt.
  5. Ausblenden der Funktionsweise des Moduls vor dem Betriebssystem und anderen Modulen.

Darüber hinaus kann der Executor die Aufgabe übernehmen, die Daten verschiedener Module zu isolieren, wenn die Koexistenz von zwei oder mehr Modulen im selben Adressraum kein Sicherheitsrisiko darstellt (z. B. für verwalteten Code) und die Arbeit des Executors selbst so stabil ist, dass Fehler beim Laden auftreten Das Modul führt nicht zu Problemen bei der Arbeit des Auftragnehmers und anderer von ihm bedienter Module.

Dieses Konzept ermöglicht die Verwendung verschiedener Methoden zum Zusammenbau von Modulen in einem gemeinsamen System. Beispielsweise wird Maschinencode, der durch Kompilieren von C ++ - Code erhalten wird, von einem Executor geladen, der die direkte Ausführung in einen separaten Adressraum unterstützt, und mit der erforderlichen Laufzeitumgebung verknüpft. Verwalteter IL-Code kann von einem Executor geladen werden, der die Ausführung von verwaltetem Code unterstützt. Darüber hinaus kann die Isolierung sowohl auf Betriebssystemebene (durch Laden verschiedener Module in verschiedenen Adressräumen) als auch auf Executor-Ebene (durch Laden verschiedener Module in einen gemeinsamen Adressraum, jedoch in verschiedenen) durchgeführt werden Umgebungsdomänen).

Eine Ausnahme bildet das Ausführen von Maschinencode unter Sivelkiriya, der als Teil des Hauptbetriebssystems als Satz von Bibliotheken und / oder Prozessen ausgeführt wird. Das direkte Ausführen des Maschinencodes unter diesen Bedingungen ist nur zulässig, wenn das Fehlen von Aufrufen des Maschinencodes an das Hauptbetriebssystem unter Umgehung von Sivelkiriya garantiert ist oder wenn solche Aufrufe aus Sicht des Systems erforderlich sind. Diese Bedingung kann beispielsweise in einer kontrollierten Unternehmensumgebung sowie für Open Source-Projekte erfüllt werden. Andererseits benötigen Module, die per Definition auf die Ressourcen des Hauptbetriebssystems zugreifen, eine Möglichkeit, seine Funktionen aufzurufen. Wenn die "Sauberkeit" des Maschinencodes nicht garantiert werden kann, kann ein solcher Code im Emulationsmodus ausgeführt werden (sowie Code, der für eine andere Plattform kompiliert wurde).

Wenn Sivelkiriya als Hauptbetriebssystem gestartet wird, erfolgt die Trennung der Adressräume auf Betriebssystemebene durch den Kern. Wenn es als eine Reihe von Bibliotheken oder Prozessen unter dem Hauptbetriebssystem ausgeführt wird, können verschiedene Module in verschiedene Prozesse des Hauptbetriebssystems geladen werden, um die Isolation sicherzustellen. Systemmodule, die für die direkte Arbeit mit Geräten (z. B. Dateisystemtreibern) verantwortlich sind, werden beim Start unter dem Hauptbetriebssystem durch Module ersetzt, die dieses Verhalten emulieren, wodurch Unterschiede zu Anwendungsmodulen ausgeblendet werden.

Die oben erwähnte Laufzeitumgebung, die für eine bestimmte Sprache und einen bestimmten Compiler spezifisch ist, ist die erste von zwei Ausnahmen von der Regel, die den Datenaustausch zwischen allen Modulen nur über die Objektschnittstellen des Systems erfordert, da das Laden in den Adressraum des Moduls für dessen Betrieb erforderlich ist. Das Konzept dynamisch verknüpfter Bibliotheken, die von mehreren Modulen verwendet werden, wird in Sivelkiriya im Allgemeinen nicht unterstützt, da es auf die Implementierung der Codefreigabe abzielt, die bereits über Modulschnittstellen implementiert wird.

Die zweite Ausnahme ist die Berechtigung, dynamisch verknüpfte Bibliotheken für mehrere Module zu verwenden, die zusammen in demselben Paket bereitgestellt werden. Gleichzeitig bietet Sivelkiriya nicht die Möglichkeit, dieselbe Bibliothek mit anderen Modulen sowie den Subsystemen für die Suche nach dynamischen Bibliotheken zu verbinden.

Beim Systemstart wird ein Teil der Künstler gleichzeitig mit dem Kernel in den Speicher geladen, um die Situation zu vermeiden, in der ein anderer Künstler zum Laden des Künstlers benötigt wird, der ebenfalls noch nicht geladen ist. Dies gilt vor allem für die Ausführenden, die den Start von Maschinencode auf dieser Plattform bereitstellen. Die übrigen Darsteller werden nach allgemeinen Regeln in den Speicher geladen.

Andere architektonische Lösungen


Das Folgende ist eine kurze unstrukturierte Liste von Sekundärprinzipien für die Konstruktion der Sivelkiriya OS-Architektur. Sie sind nicht so wichtig wie die oben beschriebenen Grundprinzipien, verdienen aber dennoch Erwähnung.

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


Die erste Veröffentlichung des Zyklus finden Sie hier . Der zweite ist hier . Der vierte ist hier . Der vollständige Text des Artikels ist auf der Projektwebsite verfügbar .

More articles:


All Articles