| Zeile 12: |
Zeile 12: |
| | | Homepage = In Planung | | | Homepage = In Planung |
| | }} | | }} |
| − |
| |
| − | rizor-OS ist ein kleines Hobby-OS, bei dem ich viel über die LowLevel-Programmierung lernen möchte.
| |
| − | Das OS soll später als Projektarbeit und Referenz für und nach dem Studium gelten.
| |
| − | Unter Umständen wechsele ich das Projekt zu einem OpenSource-Projekt, das dann unter der GPL-Lizenz laufen würde.
| |
| − |
| |
| − | == Entwickler ==
| |
| − | * [[Benutzer:rizor | rizor]]
| |
| − |
| |
| − | == Userinterface ==
| |
| − | Zur Interaktion mit dem User sind einfache Terminals geplant.
| |
| − | Später soll es dann auch ein Kernel-Terminal geben, das genau angibt, was geschieht und wie die momentane Situation
| |
| − | im Kernelspace aussieht.
| |
| − | Der User hat dann auch die Möglichkeit, den Kernelspace bedingt zu verändern um Probleme zu beheben.
| |
| − | Es soll aber nur eingeschränkten Zugriff geben, damit der Kernel nicht zerstört wird.
| |
| − |
| |
| − | == OS-Design ==
| |
| − | Es soll ein elementarer Hybridkernel angeboten werden.
| |
| − | Dieser soll auch ein elementares Filesystem haben, damit er die Boot-Files lesen und die entsprechenden Module laden kann.
| |
| − | Manche Module sollen dabei direkt in den Kernelspace geladen werden (z.B. PIC, erweiterte Speicherverwaltung).
| |
| − | Alle anderen Module sollen dann im Userspace arbeiten.
| |
| − | Dadurch soll eine größtmögliche Portierbarkeit auf andere Architekturen ermöglicht werden.
| |
| − | Außerdem sind dann leichter Erweiterungen und Updates möglich.
| |
| − | Jeder Task, der einen Syscall anbietet, muss außerdem einen Broadcast-Handler anbieten, damit der Kernel in
| |
| − | regelmäßigen Abständen die Funktion der einzelnen Tasks gewährleisten kann.
| |
| − | Wenn der Task nach einer bestimmten Zeit nicht reagiert, wird dieser beendet und automatisch vom Kernel neu gestartet.
| |
| − | Falls dieser Task zur Interaktion mit anderen Tasks verwendet wurde, wird jedem Task ein Signal geschickt, das ihm sagt, dass
| |
| − | er seine Informationen noch einmal schicken soll.
| |
| − | Es sei denn, die Informationen befinden sich noch in einer Liste o. ä., die abgearbeitet wird.
| |
| − |
| |
| − | == Modulkommunikation ==
| |
| − | Ein Modul registriert sich im Kernel als Modul an gibt eine Beschreibung ab (meistens den Namen der Hardware die es verwaltet).
| |
| − | Außerdem muss das Modul einen Speicherbereich angeben den es für Broadcasts vorsieht.
| |
| − | Ein Modul kann beliebig viele Methoden registrieren; es muss nur eine Beschreibung und die Anzahl an Parametern angeben.
| |
| − | Wenn es Rückgabewerte gibt, geschieht das über das normale Message-Passing des Kernels.
| |
| − | Es kann außerdem entschieden werden, ob der Prozess eine Benachrichtigung erhalten möchte, dass sein Auftrag erfolgreich umgesetzt wurde.
| |
| − | Das funktioniert aber nur, wenn das Modul solch eine Möglichkeit bietet.
| |
| − | Dadurch ist es möglich, dass die Softwareentwickler zwischen synchroner und asynchroner Kommunikation entscheiden können-
| |
| − |
| |
| − | == Interprozesskommunikation ==
| |
| − | Es wird mehrere Möglichkeiten der Kommunikation geben.
| |
| − | Zum einen gibt es Shared-Memory, Message-Passing und dann noch Message-Queues.
| |
| − | Beim Shared-Memory, müssen sich die kooperierenden Prozesse selbst um die Synchronisation kümmern.
| |
| − | Beim Message-Passing bekommt der Emfänger ein Signal, dass eine Nachricht für ihn bereit liegt.
| |
| − | Diese kann er sich dann in seinen Speicher laden.
| |
| − | Bei den Message-Queues geschieht es auch nur über Methoden.
| |
| − | Jede Nachricht wird in einen Puffer in den Kernel geladen.
| |
| − | Wenn der Sender eine größere Nachricht sendet, dann wird das über mehrere Puffer zwischengelagert.
| |
| − | Außerdem werden diese großen Nachrichten nur nach und nach in den Kernel geladen.
| |
| − | Dadurch muss der Prozess länger warten, aber der Kernel bleibt vom Speicheraufwand her gering.
| |
| − |
| |
| − | == OS-Statistiken ==
| |
| − | * Version: rizor-OS-0.1 Build 0009-Alpha
| |
| − | ** Kernel: 3819 LOC
| |
| − | ** Libc: 316 LOC
| |
| − | ** Kernel-Library: 66 LOC
| |
| − | ** Collection: 7 LOC
| |
| − |
| |
| − | == Entwicklungsstatus ==
| |
| − | * Kernel
| |
| − | ** rizor-0.3.2-Alpha
| |
| − | *** Fertigstellung der Elf-Loader
| |
| − | *** Fertigstellung des Multitaskings
| |
| − | ** rizor-0.3.3
| |
| − | *** Optimierung des Kernels
| |
| − | ** rizor-0.3.4 (Kernel für rizor-os-0.1)
| |
| − | *** letzte Optimierungen
| |
| − | ** rizor-0.4.0-Alpha (Kernel für rizor-os-0.2)
| |
| − | *** Auslagerung der Module
| |
| − | *** Shared-Memory-Handlers
| |
| − | *** Module-RPC
| |
| − | *** Messagepassings
| |
| − | *** Messagequeues
| |
| − | * System
| |
| − | ** rizor-os-0.1
| |
| − | *** Testmethoden
| |
| − | **** physikalische Speicherverwaltung
| |
| − | **** Paging
| |
| − | **** virtuelle Speicherverwaltung
| |
| − | **** Multitasking
| |
| − |
| |
| − | == Features ==
| |
| − | Folgende Features sind implementiert
| |
| − | * x86
| |
| − | * kommunikationsfähiger Hybrid-Kernel
| |
| − | ** CPUID
| |
| − | ** Physikalische Speicherverwaltung
| |
| − | ** Syscalls
| |
| − | ** Paging mit automatischer Flagwahl
| |
| − | ** Speicherverwaltung für Kernel- und User-Space
| |
| − | ** Spinlocks
| |
| − | ** voller Funktionsumfang des KBC
| |
| − | ** kompletter Keyboardhandler mit einem eigenen Keycode
| |
| − | * Teile der libc
| |
| − | * Eine Kernel-Library
| |
| − | * Eine Collection an Datenstrukturen
| |
| − |
| |
| − | == Roadmap ==
| |
| − | * rizor-OS-0.1 (Release: März/April 2009):
| |
| − | ** '''Feature Freeze''': 31.03.2009
| |
| − | ** '''Geplanter Release''': Ende April/Anfang Mai
| |
| − | ** Multitasking (einfaches Round-Robin ohne Thread-Support)
| |
| − | ** Speicherverwaltung mit einfachem First-Fit
| |
| − | ** libc (nötigste Implementierung)
| |
| − | ** Treiber für das Display und die Tastatur im Kernelspace
| |
| − | * rizor-OS-0.2 (Release: August-Oktober 2009):
| |
| − | ** Speicherverwaltung optimieren
| |
| − | ** Multitasking erweitern
| |
| − | *** Threads implementieren
| |
| − | *** Round-Robin mit Prioritäten
| |
| − | *** Multi-Level-Feedback
| |
| − | ** Shell-Integration
| |
| − | ** Auslagerung der Treiber in den Userspace
| |
| − | ** Dateisystem
| |
| − | ** vollständige libc
| |
| − | ** Portierung des GCC
| |
| − | ** Einbau eines kleinen Texteditors
| |
| − | * rizor-OS-0.3 (Release: 2010):
| |
| − | ** Netzwerktreiber
| |
| − | ** kleiner konsolenbasierter Browser
| |
| − | ** kleinen Dateimanager
| |
| − | ** Multitasking erweitern
| |
| − | *** shortest-job-next
| |
| − | *** longest-job-next
| |
| − | *** Wechsel des Scheduling-Verfahrens zur Laufzeit
| |
| − | * Entfernte Planung:
| |
| − | ** Teile der Treiber sollen in den Kernel verlagert werden um ein optimales Leistungs-Stabilitätsverhältnis zu gewährleisten
| |
| − | ** Portierung auf x86-64
| |
| − | ** guter Treibersupport (unter Umständen ein Einbau der CDI)
| |
| | | | |
| | [[Kategorie:Betriebssystem]] | | [[Kategorie:Betriebssystem]] |