Re: Neuer Kleinkern

  • From: Friedrich Gräter <webmaster@xxxxxxxxxxx>
  • To: <hydrixos@xxxxxxxxxxxxx>
  • Date: Tue, 13 Nov 2001 18:39:46 +0100

Naja, im Deutschen !?

egal. Ich hab mir ein recht interesanntes Buch über Kleinkerne
durchgelesen, und sehr interessante Methodiken zur
Prozessverwaltung gelesen, andererseits mit Bochs einwenig rumgespielt und
bin zu der Erkenntnis gekommen, dass im Prinzip
der künftige Kleinkern gehen müsste. Ich will allerdings zu gunsten der
Geschwindigkeit die Speicherverwaltung verändern, eventuell
noch andere Dinge zu Gunsten der Geschwindigkeit ändern. Dazu lese ich
doch besser auch mal Bücher durch. Ich hab zwar (*angeb*)
gemerkt, dass viele Ideen in HydrixOS auch anderswo Praxis sind, die ich
mir aus den Fingern gezogen habe, aber es doch recht interessante Bücher
zum Thema "Mikrokernelsysteme" gibt. Ich werde mir vor dem
Entwicklungsbeginn die Bücher / das Buch "reinziehen" und meine Schlüsse
hier nocheinmal erwähnen.

Der Grundgedanke, HydrixOS als Kompatibles und Stabiles OS zu entwerfen,
denke ich, darf nicht gegenüber der Schnelligkeit der
Ausführung verworfen werden. Wenn, dann sind es eher Dinge wie übermäßig
Komplizierte Speichermodelle o.ä. oder übermäßige
Sicherheit, die ich einsparen kann. Daher auch das Kleinkernmodell. Der
Kleinkern soll nur die Ausführung (Ausführung der einzelnen Threads und
der Threadwechsel) und die Speicherverwaltung erledigen. Was den Rest
betrifft: das ist in erster Linie sekundär.

Wichtig ist eins, es sollte ein Kern sein, der austauschbar ist, ohne,
dass das Kartenhaus zusammenfällt. Also sollte z.B. jederzeit
ein 64-bit Kern eingebaut werden können, ohne, dass der Rest sonderlich
betroffen ist. Dies führt dazu, dass sowohl Emulations-, als
auch Translationsmodule bzw. Translationsausführungsmodule so unterstützt
werden müssen, dass sie ein Teil einer Abstraktionsschicht sind,
die jedoch portabel ist. Wir übersetzen also über einen "HydrixOS-Code".
Also übersetzt ein Übersetzer in den HydrixOS-Code und
der im Kernel dann in den des Prozessors. Bei Emulatoren ist dies weniger
Problematisch, denn bei ihnen würde nur eine Rekompilierung
genügen (eventuell kleinere Anpassungen auf die Zielplattform z.B. wegen
Paddings oder Endianess usw.)

Also, um die zukünftige und schon immer dargewesenen Ziele von HydrixOS
einfach mal festzuhalten:

1. HydrixOS soll stabiles abarbeiten von HydrixOS-Anwendungen ermöglichen
(also HydrixOS-Anwendungen durch Maßnahmen
zum stabilen Arbeiten zwingen)

2. HydrixOS soll Programmen anderer Systeme das Arbeiten in der
HydrixOS-Umgebung zusammen mit anderen Anwendungen der
HydrixOS-Umgebung oder anderen Umgebungen ermöglichen. Wobei sich das in
erster Linie auf Programme von Multitaskings-Systemen
und solchen Systemen, die Messaging und geschützten Speicher kennen,
beschränkt. (DOS-Programme u.ä. müssten dann in
speziellen Verfahren ausgeführt werden)

3. HydrixOS soll das Betriebsystem stabil und sicher arbeiten lassen und
selbst IRQ-Dienste sollten das System absturtzsicher halten.

4. HydrixOS soll möglichst modular und plattformunabhängig organisiert
sein. Durch das Client-Server-Modell von HydrixOS, soll es
HydrixOS-Anwendungen möglich sein, einerseits stabil, andererseits
möglichst abwärtskompatibel die Systemdienste nutzen zu können. Wichtig
hierbei ist, dass HydrixOS den 32-bit / 64-bit Prozessorwechsel der
Intel-Prozessoren überleben können muss und dies ist nur durch eine
modulare Architektur möglich, die bereits auf Kernebene beginnt.

5. HydrixOS sollte trotz allem noch schnell arbeiten können. Dies ist zwar
sicherlich nicht in extremen Maße möglich. Denn für Emulation
im Sinne von HydrixOS gilt, dass sie viel CPU-Zeit kostet und für
Translation, dass sie viel Speicher kostet.

Ein Media-OS kann HydrixOS einfach nicht werden. Es wird Multimedial
vielleicht fähig sein, jedoch geht es mir darum ein OS zu
schreiben, das überall alles einsetzen kann. Um endlich das Mac/PC-Problem
z.B. zu lösen. Und das andere ist eigentlich banal. Es geht
darum möglichst bald Programme für HydrixOS zu haben und zwar viele. Bis
wir selbst ein Office-Paket auf die beine stellen können,
würde es Jahre dauern. So können wir die Office-Pakete anderer Systeme
bereits nach einiger Zeit nutzen.

Ich werde auf alle Fälle meine Bücher durchlesen und dann ohne zu
Spezifizieren das Programmieren anfangen. Natürlich berichte ich
euch dann! Wäre ganz nett, wenn ihr (bitte auch negativ) eure Meinung über
diese "5 Grundsätze" sagt.

cu

FG


---
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: