| Zeile 1: | Zeile 1: | ||
{{Infobox OS | {{Infobox OS | ||
| − | | Name = RedEagle-OperatingSystem | + | | Name = RedEagle-OperatingSystem (Projektname) |
| − | | Version = 0. | + | | Version = Betriebssystem: 1.00<br>Kernel: 0.10.0 |
| Entwickler = [[Benutzer:RedEagle]] | | Entwickler = [[Benutzer:RedEagle]] | ||
| Lizenz = [http://creativecommons.org/licenses/by-nc-sa/2.0/de/ CC by-nc-sa 2.0] (GPL geplant) | | Lizenz = [http://creativecommons.org/licenses/by-nc-sa/2.0/de/ CC by-nc-sa 2.0] (GPL geplant) | ||
| Zeile 10: | Zeile 10: | ||
| IPC = [[Pipe|pipes]] | | IPC = [[Pipe|pipes]] | ||
| Plattform = [[x86|i586]] | | Plattform = [[x86|i586]] | ||
| − | | Homepage = [http://www.redeagle-operatingsystem.de.vu/ www. | + | | Homepage = [http://www.redeagle-operatingsystem.de.vu/ Projektseite]<br>[http://www.youtube.com/1000Tode YouTube-Channel] |
}} | }} | ||
RedEagle-OperatingSystem ist ein 32Bit OS dessen Hauptziel darin besteht einfach und unkompliziert auf lowlevel-ebene Programmieren zu können. Das System dient quasi nur als Unterstützung für den Programmierer und soll ihn nicht bevormunden. | RedEagle-OperatingSystem ist ein 32Bit OS dessen Hauptziel darin besteht einfach und unkompliziert auf lowlevel-ebene Programmieren zu können. Das System dient quasi nur als Unterstützung für den Programmierer und soll ihn nicht bevormunden. | ||
Ziel ist es '''nicht''' ein sicheres und stabiles System zu schreiben. Diese Punkte werden frühstens in der Nächsten Generation berücksichtigt :) | Ziel ist es '''nicht''' ein sicheres und stabiles System zu schreiben. Diese Punkte werden frühstens in der Nächsten Generation berücksichtigt :) | ||
| + | |||
| + | == Namensänderung == | ||
| + | Das gesamte Betriebssystem wird seit der Kernel-Version 0.10 Adversys genannt.<br> | ||
| + | Das Projekt heißt weiterhin RedEagle-OperatingSystem, und der Kernel weiterhin reos | ||
== Bestandteile des Betriebssystems == | == Bestandteile des Betriebssystems == | ||
| − | + | Adversys besteht (bisher) aus den folgenden Komponenten | |
* '''reosboot''': Der Bootloader des Systems | * '''reosboot''': Der Bootloader des Systems | ||
* '''reos''': Der Kernel des Systems | * '''reos''': Der Kernel des Systems | ||
| Zeile 30: | Zeile 34: | ||
* Singeluser-system | * Singeluser-system | ||
* Pipes | * Pipes | ||
| + | * Ausführen von [[ELF]]-Dateien | ||
* alle Programme laufen in ring0 | * alle Programme laufen in ring0 | ||
* [[GDB]] interface | * [[GDB]] interface | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Pipes === | === Pipes === | ||
| Zeile 76: | Zeile 66: | ||
== sonstige Nennenswerte Besonderheiten == | == sonstige Nennenswerte Besonderheiten == | ||
| − | Ich lege viel | + | Ich lege viel Wert darauf, wirklich alles selber zu schreiben. Ich möchte nicht nur ein Kernel schreiben sondern ein Betriebssystem :)<br> |
Ich werde wohl bei einigen Tools wie einem Assembler ausnahmen machen, aber die Basis soll von Grund auf neu sein.<br> | Ich werde wohl bei einigen Tools wie einem Assembler ausnahmen machen, aber die Basis soll von Grund auf neu sein.<br> | ||
| + | |||
| + | '''!! Nicht alle Ideen und Umsetzungen sind gut oder sinnvoll !!''' | ||
=== Der Bootloader === | === Der Bootloader === | ||
| Zeile 95: | Zeile 87: | ||
* Eine ramdisk per RS232 herunterladen und in den RAM schreiben | * Eine ramdisk per RS232 herunterladen und in den RAM schreiben | ||
| − | Ein weiteres tool namens '' | + | Ein weiteres tool namens ''ldelf'' lädt eine [[ELF]]-Datei (den Kernel) in den Speicher. Diese kann dann mit einem weiteren Tool ausgeführt werden. |
| + | |||
| + | |||
| + | Für die Entwicklung im Realmode wurden folgende Programme eingesetzt: | ||
| + | * bcc - ein C-Compiler der Code für den [[Real Mode]] erzeugt | ||
| + | * ld86 - Der Entsprechende Linker um eine [[Real Mode]] - Anwendung zu erzeugen | ||
| + | * nasm - Ein universeller Assembler für alles :) | ||
| + | ''bcc'' und ''ld86'' werden vom Paketmanager (opensuse & Fedora) im Paket ''dev86'' bereit gestellt. | ||
=== Das FT3fs - Dateisystem === | === Das FT3fs - Dateisystem === | ||
| Zeile 111: | Zeile 110: | ||
Die Verteilung der Dateien auf dem Datenträger wird durch eine Liste von Sektor-nummern in der Datei-spezifischen Datenstruktur der Nodes beschrieben.<br> | Die Verteilung der Dateien auf dem Datenträger wird durch eine Liste von Sektor-nummern in der Datei-spezifischen Datenstruktur der Nodes beschrieben.<br> | ||
Da das Dateisystem speziell auf mein Betriebssystem zugeschnitten ist werden keine unix-permissions unterstützt. | Da das Dateisystem speziell auf mein Betriebssystem zugeschnitten ist werden keine unix-permissions unterstützt. | ||
| + | |||
| + | === Speichermanager === | ||
| + | Ist jetzt nicht direkt eine Besonderheit des Kernels, aber ich will dennoch mal beschreiben wie ich ihn realisiert habe. | ||
| + | |||
| + | Es gibt drei Listen die in dem Speichermanager genutzt werden. | ||
| + | # Eine Liste, die freie Listenelemente enthält | ||
| + | # Eine Liste, die reservierten Speicher beschreibt | ||
| + | # und eine Liste, die freien Speicher beschreibt. | ||
| + | |||
| + | Da innerhalb des Speichermanagers nur ganze Pages reserviert werden könne um neue Listenelemente anzulegen wird direkt eine ganze reihe an Elementen gleichzeitig reserviert. Nämlich soviel, wie in einer Page platz finden. Diese Elemente werden zu einer Liste freier Elemente "verbunden".<br> | ||
| + | Wird freier Speicher angefordert wird in der Liste, die den freien Speicher beschreibt nach einem ausreichend großen Speicherbereich gesucht. Wird keiner gefunden werden entsprechend viele Pages vom Pagemanager angefordert. Der benötigte Speicher wird vom freien Speicher angezogen und durch ein neues Listenelement beschrieben welches in die Liste des Reservierten Speichers aufgenommen wird.<br> | ||
| + | Wird Speicher freigegeben wird das entsprechende Listenelement aus der Liste des reservierten Speicher in die liste des freien Speichers gegeben. Es wird geprüft ob dieser Speicherbereich an anderen freien Speicher angrenzt und verschmolzen werden kann. Falls ja, wird das überflüssige Listenelement wieder in die Liste der freien Elemente aufgenommen. | ||
| + | |||
| + | === Pagemanager === | ||
| + | Ein Pagemanager an sich ist ebenfalls nichts besonderes in einem x86-Kernel, aber naja… auch da hat jeder seine eigenen Vorstellungen wie man so etwas angeht :) | ||
| + | |||
| + | Beim Initialisieren werden die ersten 3 4MiB-Pages reserviert und an 0x00000000, 0x00400000, 0x00800000 gemapped. Für die ersten 12MiB ist die Vvrtuelle Adresse also gleich der Physikalischen. | ||
| + | |||
| + | Werden später Pages angefordert wird zunächst geprüft ob es mehr als 1024 Pages sind. Falls ja wird der Speicher in 4MiB-Pages reserviert. Wird also 5MiB angefordert werden 8MiB reserviert.<br> | ||
| + | Werden weniger als 1024 Pages angefordert werden entsprechend viele Pages reserviert und eine Pagetable gesucht, die genügend freie Plätze für den Speicher hat. Sind nicht ausreichend viele Plätze frei wird eine neue Pagetable angelegt. | ||
=== Bifröst === | === Bifröst === | ||