16
« am: 14. September 2005, 16:24 »
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:
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:
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.^^