Thema: blubbOS Design

[SSJ7Gohan]

Hallo,
ich wollte hier mal mein OS vorstellen, und bitte um Kritik. Ich würde mich ausserdem über jeden freuen, der sich an dem OS beteiligen möchte, da es ein recht großes Projekt werden sollte, wenn ich alle meine geplanten Features umsetzen will.^^
Der Name blubbOS hat sich einfach daraus entwickelt, dass mir kein besserer eingefallen ist.^^;;;

Das Konzept von blubbOS ist es, ein flexibles Betriebsystem auf der Basis eines kleinen, sicheren und schnellen Kernels aufzubauen. Wegen dem flexibelen Aufbau ist es sowohl möglich, eine POSIX kompatibele API sowie eine moderne objekt-orientierte API zu unterstützen. POSIX wird darbei unterstützt, um Anwendungen wie GCC benutzen zu können. Die API von blubbOS ist jedoch nur ein unabhängiges Interface, das eigentlich nur die richtigen Treiber aufruft.

Hier eine Skizze über den Aufbau von blubbOS:

Code: [Auswählen]


KERNEL   HARDWARE  
         |        |
     TREIBER
        |         |
 POSIX  BLUBBOS API
     |                              |
POSIX-APPS     NATIVE BLUBBOS PROGRAMME

blubbOS hat eine Exokernel ähnliche Architektur. Es unterstützt Treiber sowohl als Module, als auch als Prozesse, wie in einem Microkernel. Im Unterschied zu monolitischen Kernel, laufen Treiber aber immer im Userlevel. Prozesse können auch ohne Treiber auf die Hardware zugreifen, falls sie Rechte dafür besitzen. In einem normalen System wird dieses Feature aber nicht oder nur bei bestimmter Hardware benutzt.

Hardware Abstraktions Modell:

Code: [Auswählen]


HARDWARE
     |  |  
     |  |  
     |  |           KERNEL
     |  |             |    |
     |  MODULE    |
     |    |                |
     |    |                |
     |    |                |
PROZESSE / THREADS

Der Kernel von blubbOS ist nur sehr klein gehalten und verwaltet nur folgende Bereiche:
- Speicher (Prozesse können pageweise Speicher anvordern; Shared-Memory)
- Prozesse (Prozesse sind in blubbOS die Resourcen, die ein Programm besitzt, in Form von Speicher, Filehandles, usw. (sofern das vom Treiber so implementiert wird, der Kernel verwaltet keine Files)
- Threads (Threads sind einem Prozess zugeordnet und haben einen eigenen Stack)
- Module (Module können geladen, und in alle Prozesse gemappet werden, so dass schnelle Treiberaufrufe über normale JMPs möglich sind. Als Module sollten möglichst nur die geschwindigkeitskritischen Codeteile geladen werden.)
- Interrupts (Sobald ein Interrupt auftritt wird an den Thread, der ihn handlet ein Signal gesendet. Eventuell wird der Thread auch direkt aufgerufen.)
- I/O (Der Kernel kann den Threads den Zugriff verschiedene Hardwareteile ermöglichen. Er greift jedoch nicht selbst auf die Hardware zu (mit Ausnahme von eingebauten Debugfunktionen und Speicher). Ein Thread darf nur auf einen Hardwareteil gleichzeitig zugreifen, und normalerweise ist nur Treibern der Zugriff auf die Hardware gestattet.)
- Eventuell sollte noch der V8086-Mode unterstützt werden, um das BIOS aufrufen zu können. (Noch nicht implementiert)

Die native API von blubbOS besteht aus verschiedenen Objekten. Ähnlich wie bei CORBA, unterscheidet die API zwischen Client und Servercode. Ein API-Aufruf besteht eigentlich nur aus einem kleinen Codestück, das den Aufruf an einen Server weiterleitet. Der Server führt die angeforderte Aktion aus, und leitet die Rückgabe an den Client weiter. Die Kommunikation zwischen Client und Server basiert darbei nicht auf einem bestimmten Protokol, kann also über Sockets, Pipes oder auch ganze normale Funktionsaufrufe (sofern der Server auf dem gleichen Rechner befindet, wie der Client.). Die API soll möglichst alle von den Anwendungen benötigten Funktionen abdecken, so dass die erstellten Programme eine große API benutzen, statt auf viele verstreute Module zuzugreifen. Das umfasst File-IO, IO mit verschiedenen Geräten, GUI, Netzwerk, Datenverarbeitung (z.B. XML), Sound, Grafik, verschiedene Funktionen wie REGEXP usw.

Eventuell sollte auf dieser Basis auch noch eine .NET ähnliche VM bereitgestellt werden, um eine noch größere Sicherheit zu gewähren. Mit einem JIT Compiler sollte die Geschwindigkeit ja auch nicht sooo stark dem nativen Code hinterherhinken.

Der Kernel ist in C geschrieben, die Sprache für die anderen Teile steht noch offen, wobei ich auch stark zu C tendieren würde, da dass einfach am schnellsten ist.
Die Enduser Programme würden dann wohl die VM benutzen, nicht blubOS-Native Anwendungen sollten aber auch ohne die VM laufen, und POSIX benutzen können.

Der Kernel unterstützt bereits alle oben beschriebenen Features. Die nächsten Schritte werden sein, grundlegende Treiber zu entwickeln (VFS, HD/FD Treiber, Grafiktreiber). Danach sollte die POSIX API (zumindest die grundlegenden Teile, sodass GCC und evt. Bash läuft) umgesetzt werden. Danach kann man sich an die native blubbOS API machen. Sobald die soweit ist, kann man dann eine VM und einen JIT Compiler programmieren.

Bei der Lizenz hatte ich an GPL gedacht, ich denke, für dieses Projekt hat sie eigentlich garkeine Nachteile. Das Änderungen veröffentlicht werden müssen ist ja wünschenswert, und die Treiber usw. müssen ja eh nicht GPL sein, da sie ja keinen Code direkt verwenden und sich nicht im Kernel befinden.

Den Kernel werde ich wohl in einigen Tagen mal online stellen.^^

[Kevin_]

da hast dir aber viel vorgenommen! naja die idee is cool, und besonders das mit der vm find is gut... wollte schon immer mal nen kompiler, interpreter und oder vm schreiben (würde also helfen)

[Legend]

Das Design hat sehr grosse Parallelen zu meinen Ideen. Von daher finde ich es sehr gut!

Und es stimmt, da du ja explizit alle Treiber in den User Mode "verbannst" sollte die GPL dir keine Schwierigkeiten bereiten.

Aber am Namen musst auch du (wie viele andere) noch arbeiten.

[WhiteDragon]

Name hin oder her: Da gebe ich dir mein lieber SSJ7Gohan vollkommen recht, das ist erstmal das unwichtigste. Viele planen wie wild und geben ihrem OS die hoffnungsvollsten Namen, aber es kommt nie zu gutem Code.

Und wenn ich mir anschaue, was du so bisher geschafft hast: Hut ab! Mir würde es allerdings reichen, erstmal ein Disk-Image zu erhalten, um mir einen ersten Eindruck zu verschaffen und erst später den Kernel.

Aber ehrlich: Mach weiter so, klingt großartig! Das mit der VM haben viele vor, ich hoffe, dass du es schaffst (auch wenn ich selbst Java vor .Net bevorzugen würde, aber das ist wohl Geschmacksache)!

[Legend]

Ich hab mal eine (simple) erste Version einer Java VM in nen Kernel verfrachtet und das ganze laufen lassen!

EDIT: Oh, ich habe vergessen zu erwähnen das mit den virtuellen Maschinen die rechtliche Sache evtl. nicht mehr ganz so einfach sein könnte - ich meine mal eine Diskussion gelesen zu haben ob es legal sei, auf einer freien VM eine unfreie Anwendung laufen zu lassen - bei der Klassenbibliothek ist das sowieso klar, da die Anwendung ja auch dagegen gelinkt wird, wie es auch mit nativem Code passiert.

[SSJ7Gohan]

Hm, dann müsste ich mir mal erkundigen, wie das mit unfreiem Code auf einer freien VM ist. Falls das bedenktlich ist, sollte die VM evt. unter die LGPL gestellt werden.

Als Sprache für die VM würde ich am liebsten eine C++ ähnliche Sprache verweden.

@Kevin
Es würde mich sehr freuen, wenn du mich bei der VM Programmierung unterstützen würdest.

[Osbios]

Ich bin vom Design her auch auf ein Virtualisiertes OS gekommen. Bzw. dass nur die eigentlichen Grundstrukturen als Binäri vorliegen.
Der Grund dafür war ursprünglich die Nichtbenutzung der Protected Funktionen. Also wenn die eigentlichen Programme selber keine direkten Zugriff auf den Speicher haben, dann kann auch alles im Ring 0 laufen und man erspart sich "teure" Sprünge zwischen den System- und Benutzrebenen.
Der Vorteil bei einem hier eingesetzen JIT ist, dass alle benötigten Module zu einer einheit zusammengeschmolzen werden, also dass man alle Module als Einheit sehen kann und es in der Optimierung keine wirklichen Grenzen zwischen diesen gibt.

Bei mir würden sich Treiber von Diensten und Programmen nur in ihrer Berechtigung für I/O-Schnitstellen (Ports, IRQs, spezifische Speicherbereiche)
 unterscheiden. Also auch dei Treiber werden als Virtualbinäri geschrieben.

Kernel:
Verwaltung von Speicher, I/O-Ports und IRQs

Module mit Hardwarerechten:
Treibermodule

Module ohne Hardwarerechte:
Dienste
Programme

Die grundlegende API, die das OS bereitstellt ist NUR die Verwaltung der Systemresourcen und das Ausführen von Modulen.

Ich würde aber nicht versuchen zu irgendwelchen Standards kompatibel zu sein.

Ein großes Augenmerk habe ich auf die Programmiersprache gerichtet. Ich habe vor eine eigene Sprache zu entwickeln, wobei der Programmierer sich nicht mehr auf die Geschwindigkeitsoptimierung des Quellcodes konzentrieren müssen. Die Sprache soll so strukturierd werden, dass sie mit einem Compiler ohne Probleme optimiert werden kann.

Ist zwar ein bisschen schwieriger, aber ich arbeite dran...

BTW: Diese Abgränzung zwischen einer Kernelbasis(PORTS, IRQs, MEM-Bereiche) und Module könnte der OS-Dev Zene endlich zu Standarformaten für Treiber verhelfen. Man müsste sich nur auf ein Virtualbinärformat einigen. Wie das ganze dann erstellt wird oder wie ein Kernel es interpretiert kann dann der Programmierer entscheiden.

[SSJ7Gohan]

Ich habe mein Konzept seit dem letzten Post hier auch etwas geändert, das Konzept sieht jetzt so aus:

Das OS besteht aus einem kleinen Kernel der Prozesse, Thread, Speicher und Rechte für IO/Speicher verwaltet. Alle Anwendungen, die in einer sicheren Sprache geschrieben sind, laufen in Ring0. Anwendungen in unsicheren Sprache laufen in Ring3. Für die Beschleunigung des Ring0 Codes sorgen ein oder mehrere JIT Compiler. Die Treiber unterscheiden sich bei mir nicht von Anwendungen, mit der ausnahme, das wichtige Treiber in alle Prozesse gemappt werden _können_. Der Kernel ist in C implementiert und bereits fertig. Ein Java JIT, der selbst auch in Java geschrieben ist, ist auch in der Entwicklung (viel mehr als ein Hello World kriegt er nicht hin, aber alle Grundlagen (Methodenaufrufe, Klassen, Arrays usw.) sind komplett fertig, es fehlen nur noch Instructions die in 5-6 Zeilen Code implementiert werden können, wie ADD, SUB und so weiter^^. Allerdings kann der Compiler im Moment nur AOT kompilieren, da ich noch keinen JIT-Linker habe, und daher ld verwende, um den Code zu linken. Wenn du eine eigene Sprache schreibst, könntest du dich mal mit mir in Kontakt setzen, und wir könnten uns auf Standarts für die JITs einigen, so das sie portabel auf mehreren OS und mit dem gleichen Linker laufen.

[Osbios]

Naja was heißt unsichere Sprache? Wenn du es durch deinen eigenen JIT durchlaufen lässt hast du auch die endgültige kontrolle über das Programm.
Ich für meien Teil habe mir vorgenommen NUR mein (noch nicht exestirendes) VBin Format zu benutzen.
Und das Problem von puren x86 Code leigt ganz einfach darin, dass ich nur im Ring 0 arbeiten will, und ich x86 Code erst paranoit überprüfen/modifizieren müsste um die Systemsicherheit zu erhalten.

Zur eigenen Progsprache:
Ich habe noch nichts konkretes in der Hand. Momentan bin ich noch dabei die Grundlagen der Informatik auseinanderzunehmen.
Dabei habe ich schon große Fortschritte gemacht bin jetzt aber bei solchen Sachen wie Platformunabhängigkeit, Template, Datentypen, Reduktionismuss, ... noch stark am grübeln.  :-k

Aber für alle die ihren eigene Sprache schreieben wollen, es geht eigentlich nur um:
Ein-/Ausgabe, Arithmetik (auch Binärlogik und Vergleiche), Verzweigungen und Variablen.

Übrigens: kann mir jemand was über Variablen ohne genaue Datentypen erzählen? Gibt es ja auch bei Net oder Java. Und ich meine nich nur bei Templates.

[SSJ7Gohan]

Eine sichere Sprache, ist eine Sprache, die halt vom Design her sicherstellt, das Programme nicht wild im Speicher rumschreiben/auf die Hardware zugreifen können, sondern kontrolliert werden. Das macht ja in meinem Fall der JIT, wie du schon gesagt hast.

Naja, die Sprache muss ja nur Arithmetik, Kontrollfluss, und Variablen/Objekte verwalten können. Für die I/O Sachen kann man native Methoden benutzen, oder Treiber aufrufen, die dann native Methoden nutzen.^^

[Osbios]

Sichere Sprache ist meiner Meinung nach eine schlechte Definition. Nur die Ausführung muss halt sicher sein. Denn im Endefekt machst du aus einem Quellcode einer Sprache (sicher oder nicht) eine "Binärdatei", welche aber nicht vor Veränderungen geschützt ist oder halt anders erstellt wurde.
Man könnte als besser "sichere Ausführungsschicht" sagen.

Und wie ruft man diese externen Methoden auf? Über I/O Funktionen der Programmiersprache!
Ich meinte auch nicht die Hardware-I/O sondern Funktionsaufrufe zu externen quellen. Die Module müssen ja auch irgendwie meiteinander und mit dem Kernel kommunizieren. Das Eingabe-Verarbeitung-Ausgabe Prinzip dürfte dir ja bakannt sein.

Und was genau meinst du mit Kontrollfluss?

[SSJ7Gohan]

Jumps (Gotos), Vergleiche und sowas.

[Legend]

Ja, eine sichere Sprache ist natürlich nur sicher wenn man den Code vor dem ausführen überprüfen kann. Also sicherstellen das der z.B. bei der JVM der Bytecode wirklich zu einem Java-Programm gehören kann.

Wenn du aus Javacode x86-Instruktionen erzeugst kannst du diese natürlich nicht mehr zur Laufzeit validieren, das stimmt schon. Andererseits kannst du z.B. C/C++ Code der noch gar nicht kompiliert wurde auch nicht so validieren das man sagen könnte das man den Code ohne Speicherschutz laufen lassen könnte, was bei Java-Quellcode jedoch gegeben ist.

Deshalb ist das ganze natürlich nur richtig sicher mit fremdem Code wenn wenn, diese "sichere Ausführungsschicht" vorhanden ist, aber ohne sichere Sprache wirst du diese gar nicht erst programmieren können.

Natürlich stellt sich auch die Frage ob man innerhalb der Klasse von sicheren Sprachen noch so einschneidende, aber potenziell lohnenswerte Veränderungen machen kann. Wahrscheinlich geht das, jedoch kann man damit schon ein eigenes Projekt füllen und besonders in der aktuellen Situation mit den verschiedenen virtuellen Maschinen finde ich es doof sich auf eine zu beschränken.

Sagen wir mal so, ich hatte mir auch ein Konzept überlegt, wo mehrere virtuelle Maschinen zum Einsatz kommen können, wobei ich selber keine neue erfinden wollte weil ich mit Java und C# eigentlich ganz zufrieden bin. Jedoch hielt mein Konzept auch den Weg zur Integration von "Eigenkreationen" frei ...

[Osbios]

@SSJ7Gohan:
Vergleiche habe ich bei Arithmetik untergeordnet. Das ist mein momentaner Weg alles auf wenige Grundlagen zu reduzieren. Z. B. in C (C++?) ist der Wert 0=false und 0<>true. Daher bekommen bedingte Sprünge eigentlich nur einen Zahlenwert.

Code: [Auswählen]

2 == 2 ist 1
2 == 3 ist 0
2 <> 2 ist 0
2 <> 3 ist 1

@Legend:
Den einzigen großen Unterschied von C++ und Jave, den ich kenn ist der Verzicht auf direkte Pointer in Java. Was gibt es da sonst noch? Habe von Jave leider keine Ahnung.

[SSJ7Gohan]

Von der Sprache her:
-> Keine Mehrfachvererbung, dafür gibt es Interfaces, die jede Klasse implementieren kann, die eingentlich nur abstarkte Klassen sind.
-> Kein Operatoroverloading
-> (Leider) keine unsigned Variablen
-> Bessere, umfangreichere Standardlib.
-> Es fehlt sicher noch sehr viel, das was hier steht ist mir grad mal so eingefallen.

Vom Design her:
-> Wird zu Bytecode kompiliert.

[Osbios]

Von der Sprache her:
-> Keine Mehrfachvererbung, dafür gibt es Interfaces, die jede Klasse implementieren kann, die eingentlich nur abstarkte Klassen sind.

Da mit kenne ich micht nicht so gut aus.

-> Kein Operatoroverloading

Ich wollte in dem Sinne auch eine recht undynamische Sprache machen, die nichts der gleichen unterstützt.

-> (Leider) keine unsigned Variablen

Warum nicht? Ich weiß jetzt wirklich nicht warum unsigned nicht benutzt werden sollten/können...

-> Bessere, umfangreichere Standardlib.

Damit sind wahrscheinlich die ganzen API aufrufe gemeint, die nicht vom Programm erzeugbare Funktionen zur verfügung stellen.

-> Es fehlt sicher noch sehr viel, das was hier steht ist mir grad mal so eingefallen.

Hat mir dennoch einen tieferen Einblicke gegeben.

Vom Design her:
-> Wird zu Bytecode kompiliert.

OK, das war klar.

[Legend]

Nun ja, sagen wir mal so, der Verzicht auf Pointer verhindert erstmal genau das man wild im Speicher rumschreiben kann, weil ich immer mal +X rechnen können muss mit dem Pointerkonzept. Ohne Alternativen würde dieser Verzicht natürlich auch sinnvolle Programme verhindern.

Deswegen gibt es bei Java Referenzen auf Objekt und Arrays mit Bounds-Checking als Ersatz, so dass man auch keine Pointer braucht.
Mit diesen Möglichkeiten kann man kein Bit Speicher das ausserhalb des dem Programm zugeteiltem Bereich liegt erreichen.

Dadurch kann man Java Programme unbesorgt in den selben Addressraum packen, solange nirgendwo ein Bug ist können die sich nicht gegenseitig überschreiben. Hierzu muss man noch sicherstellen das es Java Programme sind, zum Bytecode ist in der VM Spec der JVM beschrieben wie man das macht.

Auch bei syntaktisch korrekten C Programme kann man so eine Aussage nicht machen. char* ptr = 0xABCDEF; memset (ptr, ...); ?

[Osbios]

Ich habe mir jetzt schon viele Gedanken über die möglichen Programmierstrukturen und das Ausgabeformat gemacht.
Wie kann man beides voneinander unabhängig entwickeln?
Hört sich seltsam an?
Dass soll einfach nur heißen: wie kann man die eigentliche Programmiersprache weiterentwickeln und mit neuen Programmiertechniken versehen ohne gleich ein neues Ausgabeformat zu benötigt.

Dafür muss allerdings erst ein solides Ausgabeformat her. Mit diesem Format könnte man dann auch getrente Wege gehen und jeweils eigene Compiler entwickeln.

Was ich bis jetzt vom Inhalt dieses Formates sagen kann ist:
-sollte möglichst schnell und einfach von einem Programm zu lesen sein.
-Baumstrukturen für Abhänigkeiten von Variablen oder Verzweigungen
-Eventuell eine aufteilung in Initalisierungsteil und Laufzeitteil

Also besonders solche Sachen die eine JIT Optimierung benutzen kann.

Bei den Abhänigkeitsstrukturen kann das noch ein bisschen schwerer werden. Als kleines Beispiel:

Code: [Auswählen]

X = sin(y)/pi+pi*360
if Bedingung1 then A = Xkann vom Compiler ganz einfach in

Code: [Auswählen]

if Bedingung1 then A = sin(y)/pi+pi*360umgewandelt werden.

Aber was ist in einem solchen Fall:

Code: [Auswählen]

X = sin(y)/pi+pi*360
if Bedingung1 then A = X
if Bedingung2 then B = X
Wenn nur eine der Bedingungen ausgeführ wird soll sin(y)/pi+pi*360 gerechnet werden. Sind jedoch beide Bedingungen erfüllt soll sin(y)/pi+pi*360 dennoch nur einmal berechnet werden.

Es gibt viele Dinge die man beachten muss, z.B. ob man die Dateien grundsätzlich in little-endian abspeichert und damit zukünftige Platformen wie PPC benachteiligt.

Ich möchte dem JIT halt soviel wie möglich vorkauen um eine optimale Geschwindigkeit zu erreichen.

[SSJ7Gohan]

Naja, ich würde erstmal die Sprache selbst festlegen, bevor ich das Ausgabeformat festlege.

Die VM würde ich auf einer virtuellen Maschine mit beliebig vielen Registern aufbauen und nicht auf einem Stack wie in Java oder .NET. Das hat den Vorteil, das man einige Optimierungen besser vornehmen kann, wie z.B. Typchecks zur Compilierzeit. Die Register kann man dann teilweise 1:1 auf die realen Register übertragen und muss nicht den Umweg über Stackzugriffe nehmen.

Ob du Little oder Big Endian benutzt ist nicht wirklich wichtig, der JIT muss dann zwar eventuell beim Laden der Anwendung etwas rumshiften, aber das solle keinen bemerkbaren Performanceunterschied geben.

[Legend]

@Osbios: Für den 2. Fall hast du wahrscheinlich die optimale Möglichkeit (ohne das man irgendwelche Verteilungen vom Eintreten der Bedingungen kennt) schon hingeschrieben!

Du hast aber einen grundlegenden Unterschied schon mal zum Java Bytecode drin der schon mal ein potenzieller Grund für ein neues Format darstellt: Du willst alles für maximales Tempo drin. Der Java Bytecode sollte in erster Linie kompakt sein, damit die Programme schnell übers Internet übertragen werden können.

Allerdings ist deine Forderung nach einem halbwegs universellem, sicherem Bytecode ähnlich der Anforderungen des Bytecodes von .NET.

@SSJ7Gohan: Ja, das mit der Maschine mit unendlich vielen Register kam mir auch mal in den Sinn. Jedoch hatte ich mal gelesen das die stack-basierten Maschinen ein Stück mehr erforscht sind als die register-basierten. Jedoch verwendet GCC an einer Stelle in seinem Kompilierprozess so eine Register-Maschine! Jedoch brauchst du immer noch einen Algorithmus zur Register Allokation, ausser der Code braucht weniger Register als die CPU hat.

Nun ja, vieles kann man zur Ladezeit machen. Programme die Daten über das Internet verschicken wollen werden aber sich aber darauf verlassen müssen das die Daten die sie zur Laufzeit erzeugen die richtige Reihenfolge haben.

Ich denke optimales Tempo kann man wahrscheinlich erreichen indem man Instruktionen die möglichst nahe an klassichen CPUs liegen anbietet, jedoch ohne die Sicherheit zu gefährden, sonst kann man sich ne VM auch praktisch sparen!