HydrixOS Newsletter - Die neue Architektur

  • From: Friedrich Gräter <webmaster@xxxxxxxxxxx>
  • To: <Undisclosed-Recipient:@post.webmailer.de;>
  • Date: Sun, 11 Nov 2001 19:26:58 +0100

Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

HydrixOS Newsletter

-------------------------------------------------------------------------=
-------


Hallo,
es ist nun endlich genug Spezifiziert, Dokumentiert und sonst-was getan =
worden. Es wird endlich Zeit zu programmieren, denn sonst droht HydrixOS =
einzuschlafen, und das w=E4re das letzte, was passieren sollte.=20
Daher will ich in diesem Newsletter nur die Spezifikationen zum Kern =
ver=F6ffentlichen.


-------------------------------------------------------------------------=
-------


1. HydrixOS ist ein Mikrokernelsystem
Die einfachste Form der Systemabstraktion ist das Mikrokernelsystem. Sie =
hat gegen=FCber dem veralteten monolythischen Modell den Vorteil, dass =
im System alles sauber abgeriegelt ist. Alles ist ein Prozess, selbst =
Treiber. Das einzigste, was kein Prozess ist, ist der
Kernel. Jedoch sind im neuen HydrixOS Kernel nur noch folgende Dienste =
enthalten:

- Speicherverwaltung
- Speicherzugriff / Zugriffspr=FCfung
- Emulations / =DCbersetzungsmodule
- IRQ-Verwaltung und Behandlung
- Steuerung des virtuellen Arbeitsspeicherdienstes
- Taskwechsel
- Initialisierung des Systems
- I/O-Portverwaltung / Zugriffspr=FCfung
- Fehlerbehandlung

Alle anderen Dienste, auch die Systemschnittstelle wurden auf einen =
externen Prozess ausgelagert. Dieser Prozess hat das Recht auf den =
gesamten Speicher zuzugreifen, und kann somit die Systemtabellen und =
Prozesse manipulieren. D.h. er kann alle n=F6tigen API-Dienste anbieten. =
Dies hat den Vorteil, dass die wichtigsten Kerneldienste =
(Prozessverwaltung, Dateisystem etc.) v=F6llig Multithreaded arbeiten =
k=F6nnen. Nur die Dienste, die durch Multitasking gest=F6rt werden =
k=F6nnten, sind im eigentlichen Kernel. Allerdings ist auf Kernelebene =
dann keine Sicherheitspr=FCfung mehr vorhanden, da diese dort nicht mehr =
von N=F6ten ist.
Folgende Grafik erl=E4utert den Aufbau des Systems:



2. Speicherverwaltung und Zugriff
Die Speicherverwaltung wurde nun an andere Systeme mehr angelehnt. Jeder =
Prozess hat seinen eigenen 64-Bit Speicher, der aus Seiten des =
virtuellen und des physikalischem Speichers besteht. Sowohl der globale, =
als auch der lokale Speicher ist in Segmente unterteilt, so dass im =
globalen Speicher, die Prozesse sich nicht gegenseitig st=F6ren k=F6nnen =
und im lokalen Speicher der Prozess keine Puffergrenzen =FCberrennen =
kann, ohne es zu merken. Der gesamte Speicher ist in Seiten von a 4096 =
Bytes unterteilt. F=FCr den globalen Speicher gibt es eine Tabelle, die =
anzeigt welche Seite im virtuellen und welche im physikalischen Speicher =
liegt und welchem Prozess welche Seite
geh=F6rt. Im lokalen Speicher ist eine hardwareabh=E4ngige Tabelle, die =
anzeigt welcher globalen Seite die aktuelle lokale Seite entspricht.
Ist eine Seite im virtuellen Speicher, wird der Verwaltungsdienst f=FCr =
den virtuellen Speicher aufgerufen, der wiederum die gew=FCnschte
Seite in den physikalischen Speicher herunterl=E4dt und den Eintrag in =
der lokalen Seitentabelle entsprechend anpasst.


Beim Speicherzugriff wird vom System nur gepr=FCft dass der Prozess =
keine Segmentgrenzen verletzt. Die Sicherheit wird hingegen
nur gepr=FCft, wenn ein neues globales Segment dem Prozessspeicher =
hinzugef=FCgt wird. Der Prozess kann selbst=E4ndig seinen Speicher
nicht verlassen, denn die Speicheradressierung findet nur =FCber lokale =
Zeiger statt, die anzeigen:

- In welchem lokalen Segment die Ressource enthalten ist
- An welchem Offset diese zu finden ist

3. Ausf=FChrung der Tasks
Unter HydrixOS ist nun beides m=F6glich: =DCbersetzung und Emulation. Im =
Kernel sind sog. Task Processing Units, die einen Task (also=20
etwas, das ausf=FChrbar ist - z.B. ein Thread) auf irgendeine Weise =
ausf=FChren und sich nach eigenverantwortlich an die HydrixOS-Regeln
halten m=FCssen. Diese TPUs k=F6nnen entweder wie gesagt Programme =
emulieren oder =FCbersetzten Programmcode ausf=FChren. Um die
TPUs zu unterst=FCtzen sind entsprechende Header-Dateien verf=FCgbar, =
auf deren Basis ein stabiles TPU programmiert werden kann. Die
Stabilit=E4t des Systems h=E4ngt nur noch an den TPUs.

4. Taskwechsel
Das System ist f=FCr den Wechsel der Tasks verantwortlich. In einer =
Liste sind alle auszuf=FChrenden Threads gespeichert. Ist die =
Arbeitszeit eines Threads abgelaufen, wird ein Flag durch den =
Uhren-Treiber gesetzt, dass die aktuelle TPU veranlasst die Ausf=FChrung =
des aktuellen
Tasks abzubrechen und die Kontrolle an den Kernel zur=FCckzugeben. Der =
Kernel wechselt dann zu einer anderen TPU, die einen anderen Task =
ausf=FChren soll.

5. Interrupts
Wird ein IRQ (=3D Interrupt Request) durch ein Ger=E4t ausgel=F6st, =
geschieht =E4hnliches. Die aktuelle TPU wird angewiesen, den aktuellen
Task einzufrieren und sich vorzubereiten einen anderen Task =
auszuf=FChren, jedoch wird die aktuelle Ausf=FChrungsroutine nicht =
abgebrochen.

6. Botschaften
Damit ein Thread einem anderen Thread bestimmte Kommandos senden kann, =
gibt es unter HydrixOS ein Botschaftensystem. Ein
Thread sendet =FCber den Systemkern eine Botschaft an einen anderen =
Thread. Das ist das Grundmodell. Jeder Thread hat eine Funktion
die st=E4ndig auf neue Botschaften pr=FCft (jedoch h=E4lt das System =
einen Thread an, wenn es keine Botschaften gibt, um den Prozessor
zu entlasten).=20
Nat=FCrlich kann ein Thread auch mehrere Botschaften gleichzeitig =
empfangen. Das System reiht diese nacheinander in eine Warteschlange,
so dass jede Botschaft nacheinander bearbeitet wird.
Wahlweise unterscheidet HydrixOS zwischen drei Sorten von Botschaften:

1. Normale Botschaften
2. Wartebotschaften Botschaften - bei denen ein Thread solange =
angehalten wird, bis der andere Thread die Botschaft bearbeitet hat=20
3. R=FCckrufbotschaften - dabei wird dem einen Thread eine Botschaft =
gesendet, wenn die aktuelle Botschaft bearbeitet wurde
4. Serverbotschaften (siehe 7.)

7. Klient-Server-Modell
Dies ist ein Modell, das besondere Leistungsf=E4higkeit erm=F6glicht. =
Einige Prozesse k=F6nnen sich als Server anmelden. Bei diesen =
Serverprozessen k=F6nnen sich andere Prozesse anmelden und bestimmte =
Subroutine und Speicherbereiche des Serverprozesses benutzen. Der =
Vorteil daran ist, dass ein Programm nicht mehrfach geladen werden muss, =
jedoch der Server ein Eigenst=E4ndiges
Programm bleiben kann und bei Fehlern im Server, nicht der Server, =
sondern der Klient "beschuldigt" wird.
Das Ausf=FChren der verschiedenen Funktionen erfolgt =FCber =
Serverbotschaften. Diese Botschaften sind normale Wartebotschaften, =
allerdings
mit R=FCckgabewert, der an eine bestimmte Adresse im Speicher des =
Klienten plaziert werden kann.

8. Systemaufrufe
Es gibt nur wenige Systemaufrufe, die genutzt werden k=F6nnen, denn die =
meisten API-Funktionen werden durch den oben genannten speziellen API =
Server erledigt.=20

9. Initialisierung
W=E4hrend der Initialisierung des Systems wird die Welt geschaffen, in =
der sp=E4ter HydrixOS existiert. Es werden alle Tabellen angelegt
und bereits Eintr=E4ge in diesen Programmiert, so dass mit dem =
aktivieren des Schedulers HydrixOS bereits lauff=E4hig ist und mit dem
Prozess "init" die Arbeit beginnen kann (d.h. auch, dass der API-Server =
usw. installiert ist). Init darf ohne weiteres die Konventionen
umgehen, wichtig ist hierbei nur das Ziel.


-------------------------------------------------------------------------=
-------


Wie geht es aber nun weiter? Nun, wie Sie sehen besteht der =
HydrixOS-Kernel nur noch aus sehr wenigem, aber dieses wenige, macht =
sp=E4ter HydrixOS aus. Diesen zentralen Kern werde ich doch alleine =
programmieren, da es viel zu viel Zeit kosten w=FCrde, die =
Programmierarbeit einzuteilen. Sp=E4ter, wenn Dinge wie der API-Server =
entwickelt oder die extrem wichtigen TPUs wird, hoffe ich auf die =
Unterst=FCtzung anderer Programmierer, denn die API-Server und Treiber =
kann ich nicht alleine Programmieren - und ich bin f=FCr jeden anderen =
Programmierer dankbar und m=F6chte mich hier offiziell bereits bei =
Maximilian Marx, Dennis Schwerdel und Stefan Kempf f=FCr die bisher =
geleistete Programmierarbeit bedanken!
Ich hoffe sobald wie m=F6glich die Header-Dateien des Kleinkerns und =
auch nat=FCrlich diesen selbst pr=E4sentieren zu k=F6nnen.=20

Ich hoffe auch, dass ich eine Dokumentation schreiben kann, wenn der =
Kleinkern fertig ist. Jedoch halte ich es im Moment f=FCr wichtiger, =
endlich wieder zu programmieren, denn das Interesse an HydrixOS w=E4chst =
(wie ich an der steigenden Mitgliederzahl am Newsletter sehen kann) - =
aber ich kann bisher bis auf einen Bootloader und einen Haufen Texte =
nichts pr=E4sentieren :-). Aber das soll sich schnellst m=F6glichst =
=E4ndern. Welche API und welche Schnittstellen in HydrixOS verwendet =
werden, wenn der Kleinkern programmiert ist, werde ich dann versuchen =
=FCber die Mailingliste entscheiden zu lassen.


Bis bald,

Friedrich Gr=E4ter



-------------------------------------------------------------------------=
-------

Sie erhalten diesen Newsletter, weil Sie sich unter www.hydrixos.de sich =
f=FCr diesen eingetragen haben oder sich f=FCr dessen Eintragung bereit =
erkl=E4rt haben. Sie k=F6nnen sich durch
eine Mail an newsletter@xxxxxxxxxxx wieder abmelden. HydrixOS ist ein =
Warenzeichen von Friedrich Gr=E4ter. Dieser Dienst wird durch =
www.TheMasterz.de unterst=FCtzt.=20



-- Binary/unsupported file stripped by Listar --
-- Type: image/gif
-- File: kernel.gif


-- Binary/unsupported file stripped by Listar --
-- Type: image/gif
-- File: memry.gif



---
This is not SPAM! You can unsubscribe sending an e-mail to 
hydrixos-request@xxxxxxxxxxxx with subject "unsubscribe". If
you've got questions contact webmaster@xxxxxxxxxxx .

Other related posts:

  • » HydrixOS Newsletter - Die neue Architektur