AiCOS ist ein Betriebssystem, welches ganz neue Wege gehen wird, vor allem im Kerneldesign. Warum also aus einer blöden und verrückten Idee nicht ein vollwertiges OS machen?

AiCOS Einsatzbereicht wird anfangs im Netzwerkbereich liegen, unter anderem aber auch als Storage-System. Auch wenn AiCOS auf Single-Core-Plattformen laufen wird, wird es seine Stärken wohl eher auf Multiprozessor bzw. Multicore-System zeigen können. Wichtigstes Ziel dabei ist zum Einem die Performance (ideal sogar Echtzeit) und zum Anderem die Stabilität (Redundanz bis auf CPU-Ebene).

Dieses ehrgeizige Ziel von AiCOS soll frisches Blut in die Computertechnik bringen und hoffentlich auch andere zu solchen OS-Disgns motivieren. Denn noch ist AiCOS ein ClosedSource-Projekt.

Wen wunderts also, dass AiCOS Wurzel liegen weder in der Linux/Unix-Welt noch in der Windows-Welt, sondern viel eher in Microsofts Singularity. Ein zweites Singularity soll es aber nicht werden, versprochen.

Über AiCOS

Namensgebung

Ist der Name des OS nur ein fantasievolle Bezeichnung oder steht AiCOS für eine Abkürzung? Wenn ja, was verbirgt sich dahinter?

AiCOS ist in der Tat eine Abkürzung und steht für Asyncronous interConnected Operating System. Sollte sich die Entwicklung dieses OS meinen Erwartungen entsprechen, könnte diese AiCOS in einigen Jahren auch für Artificial intelligence Controlled Operating System stehen. Klingt nach SKYNET, könnte man denken, wird aber keinesfalls beabsichtig.

Entwickler

Derzeit unterliegt die komplette Entwicklung von AiCOS einer einzigen Persion, nämlich mich, ScollPi. Dies soll aber nicht für immer bleiben. Wenn wichtigsten Konzepte des OS (überwiegend Kernel) erstellt und ggf. auch schon umgesetzt wurden, werde ich meine Türe öffnen und andere Begeisterte mit in dieses Boot nehmen.

Lizenz

Steht noch nicht fest. Derzeit ClosedSource, soll aber später, wenn ich andere mitwirken lassen, OpenSource werden.

Plattform

Erstmal nur für x86 für 32/64-Bit Plattformen.

Kernel

Beim Kernel werden ganz neue Wege gegangen. Monolithischer Kernel sowohl auch Mikrokernel mögen ihre Vor- und Nachteile haben. Klar, es gäbe noch die Hybriden. Aber die Entwicklung der Prozessoren geht ja auch weiter, Multicores haben die Zukunft. Ideal sind Multicore-CPUs, bei denen auf jedem Kern ein andere Kernel laufen könnte. Tile-Gx (100 Kerne) von Tileras geht da schon in diese Richtung. Doch selbst auf heutigen PC, in erster Linie Gaming-PC, gibs schon verschiedene Prozessoren, CPU, GPU und auch schon PPU.

Sprachen

Hardware nahe Programmteile wie Bootloader (später mehr dazu) oder Treiber werden in Assembler (Intel-Syntax) vorliegen. Der Kernel selbst wird überwiegend in C geschrieben sein. Ob C++ auch verwendet wird, wird jedoch nicht ausgeschlossen. Programme im Userspace überwiegend in C++. Ob andere Sprachen Einzug erhalten, hängt davon ab, ob entsprechende Compiler portiert werden.

API

Noch nicht Bestandteil der Entwicklung.

Binärformat

Vorerst BIN, ggf. auch EXE. Ob ELF unterstützt wird, ist eine Frage der Implementierung.

IPC-Methode

Den einzigen gemeinsamer Nenner, den ich finden konnte und auch bei der derzeitigen CPU-Entwicklung für zukunftsicher halte, sind Channels. Channels sollen später auch die Grundlage eigenes Netzwerkprotokolls werden, welches anfangs eher über IP zu einer anderen Maschine mit AiCOS getunnelt wird.

Entwicklungsumgebung

• Hardware
  • Intel Core 2 Quad mit 8 GiB RAM
• Software
  • Microsoft XP Pro >>> Windows
  • Microsoft Visual Studio 2008 Express
  • Mircosoft .NET Framework v3.5
  • Microsoft Windows-Debugger x86/x64 für Kernel-Debug
  • Microsoft Virtual PC 2007 inkl. SP 1 >>> Microsoft Virtual PC
• Referenzmaterial
  • Microsoft Singularity RDK 2.0
  • Protected Mode Tutorials
  • Paging verschiedener CPUs

Testumgebung:

Es wird immer zuerst in der VM auf dem Entwicklungssystem getestet und erst wenn da alles ohne Probleme läuft, wird auf der realen Maschine getestet. Als Test-PC dient da einmal ein P2 mit müden 400 MHz als Single-Core, um vor allem die Boot-Phasen zu testen. OK, derzeit benutze ich einen Laptop mit P3 mit 1 GHz und satten 256 MiB RAM. Versehentlich auch mal Tests auf meinem Quad-Core, wenn ich vergessen habe die Diskette nach dem Testen rauszunehmen. Aber da zeigt sich schon, dass auf der realen Maschine alles genauso läuft wie bisher in der VM.

Konzept

Bootsektor

• Der Bootsektor wird so geschrieben, dass es im Prinzip egal ist, an welcher Adresse dieser geladen und ausgeführt wird. Derzeit wird noch ein Fehlercode ausgeben und die Ausführung angehalten, wenn sich der Bootcode nicht an der Adresse 0x00007C00 befindet.
• Für jedes FS (RAW, FAT, FAT32 und ISO9660) auf dem AiCOS zum Einsatz kommen wird, wird es einen entsprechenden Bootcode geben.
• Die Aufgabe des Bootsektors sollte wohl ja klar sein, nämlich unabhängig vom Medium den Bootloader zu laden und auszuführen.

Bootloader

• Protected-Mode
• Paging mit Physical-Address-Extension (PAE), max. 64 GiByte
• Soll erste Möglichkeiten des Kernel-Debugging ermöglichen.
• Einrichten des MKS und laden bedingter Treiber.
  • Mikrokernel für den BSP (Boot Strap Processor).
  • Mikrokernel für jeden APs (Application Processors) ... nur bei MultiCore-Systemen.
  • Management-Kernel.
  • I/O-Kernel.
• Startup des MKS und Channel-System.
  • Den BSP in den 32-Bit PM schalten und die Kontrolle über den Management-Kernel geben.

Kernel

• MKS = Modulares Kernel System, unterteilt in:
  • Managemant-Kernel, verwaltet RAM und koordiniert die anderen Kernels für CPU, IO und Subsysteme.
  • CPU-Kernel, jeder Kern hat seinen eigenen Mikrokernel.
  • IO-Kernel.
  • Subsystem-Kernel, für weitere Treiber, Filter und und und ...
• Soll in sich redundant werden, erfordert aber mind. 2 CPUs bzw. 2 CPU-Kerne.

Notiz: Zum besseren Verständnis meines Konzept ist eine visuelle Darstellung meines OS in Planung. Sie beinhaltet den Bootprozess und den Aufbau des MKS. Diese Visualisierungen werden überwiegend auf der Homepage von AiCOS zu finden sein, die sich derzeit noch im Aufbau befindet.

History

Die letzten 10 Änderungen:

• 15.01.2009: Version 0.00.??.??
  • ROFS-Bootsektor-Code finalisiert, es kann nun auch eine Datei grö´ßer 64KiB geladen werden. Der Bootloader selbst wurde wegen seiner PM-Funktionalität auf 256 KiB beschränkt.
  • Suchen und Auslesen von MPS (FPS).
• 14.01.2009: Version 0.00.38.57
  • Grundfunktionen des Memory-Management
  • Suchen und auslesen des PCI-BIOS.
  • Suchen und auslesen des PnP-BIOS.
  • Suchen und auslesen von ACPI.
  • Problematische unerklärbarer Bug im Bootsektor-Code (ROFS) behoben.
• 11.01.2009 SMAP hinzugefügt.
• 04.01.2009 Bug im Bootcode behoben; Kernel-Debug implementiert (0.00.35.47)
• 03.01.2009 Printf implementiert (0.00.34.45)
• 03.01.2009 C++ Testdummy, um Einsprung zu testen; Test OK (0.00.31.40)
• 02.01.2009 Paging mit PAE implementiert. (0.00.24.23)
• 01.01.2009 Bootloader prüft die CPU, da mindestens ein 586er benötigt wird. (0.00.23.20)
• 01.01.2009 Bug im Bootcode behoben; Bootloader gibt Meldung aus. (0.00.22.16)
• 01.01.2009 Fehler beim Sprung in den PM behoben, FDD-Motor wird nun auch abgeschaltet. (0.00.21.6)
• 31.12.2008 Bootsektor: Umadressierung, da Probleme mit dem PM. (0.00.20.5)

Komplette History: http://aicos.amazing-fx.de/history.txt

Statistik

Die folgende Statistik zählte folgende Datei-Typen:

• Build-System-Dateien (.cmd, .vbs)
• MSBuild-Projekt-Dateien (.proj, .targets)
• Assembler-Dateien (.asm, .inc)
• C/C++ Dateien (.cpp, .h)

• Gesamtzeilen: 10022
  
  
• Codezeilen: 5504 (55%)
• Leerzeilen: 1985 (20%)
• Kommentar: 2533 (25%)

Gezählt wurde mit dem Java-Programm: Lines Of Code Wichtel

Stand der Dinge

Fertig:

• Bootsector für ROFS, FDD-Version.
• Bootloader
  • Entry16: 16-Bit-Einsprung in Assembler
  • Entry32: 32-Bit-PM-Einsprung in Assembler
  • Entry: C++ Part
  • Routinen für Textausgabe, darunter auch mit printf()
  • COM-Treiber: für Kernel-Debug benötigt
  • Kernel-Debug
  • SMAP (System Memory Map)

In Arbeit:

• Bootloader
  • Paging mit PAE (bisher nur 2 MiB gemappt, sollte erstmal für Bootloader-Spielereien reichen).
  • Memory Management.
  • PCI Suuport.
  • PnP Support.
  • ACPI Support.
  • ACPI (Um Anzahl der Cores zu ermitteln).
• Homepage für AiCOS.

Geplant:

• Bootloader
  • System-Shell (Kernel-Ersatz, dient zum Anzeigen wichtiger System-Informationen und wird als CLI [Command Line Interface] aufgesetzt.
• Bootsektor für CD

Roadmap

Ziele für Sprung in Research Phase 1 (Version 0.01)

• Single-CPU
• Funtionierender Bootsektor für Floppy (ROFS) und CD (ISO9660) - (Einheitlicher Code, bis auf die unterschiedliche Sektorgröße).
• Funktionierender Bootloader, der System-Vorab-Checks durchführt, bevor gewissen Funktionen wie Protected Mode oder Paging benutzt werden.
• Ausführliche Comments in Bootsektoren und Bootloader.
• AiCOS-Source-Tree, Hardwarebedingter Code wird von System-Code getrennt, damit soll später eine bessere Portierbarkeit erreicht werden, wodurch nur der Hardwarebedingte Code (überwiegend Assembler) ausgetauscht werden muss.
• AiCOS-Startup-Dummy.

Ziele für Sprung in Research Phase 2 (Version 0.02)

• Differenzierung des Kernelgrundsystem in Management-Kernel, CPU-Kernel & I/O-Kernel
• Channel-System als IPC implementieren
• Hello-World-Prozess

Aktueller Screenshot

Version: 0.00.38.57

Screenshot mit Windows-Debug

Böse Falle

• Ständig kackte meine VM ab, als mein Bootloader ins den PM-Segment prang. Man kann sich echt todsuchen, wenn man Hexzahlen und Dezimalzahlen nicht unterscheiden kann. 20d != 20h
• Und wieder einmal stellte meine VM ihren Dienst beim Sprung ins PM-Segment ein und wieder suchte ich mich blöd. War letztenendes auch logisch, wenn der Bootsektor nur ein Sektor (512 Bytes) des Bootloaders lädt, aber der Sprung in PM-Segment aber an Offset 0x0200 sich befinden. Böse Falle

Meine SourceCode-Ecke

• Bootsektor-Programmierung
  • ShowReg_32.asm :: Zeigt den Inhalt der CPU-Register beim Einprung in den Bootcode. Screenshot hier!
  • Floppy_Raw.asm :: Floppy-Raw-Bootsektor, Research-Version.
  • All_Bootsector_Images.zip :: Alle Bootsektor-Beispiele als Raw-Image für die Floppy.

Ziele

Ein vollwertiges OS auf die Beine zu stellen, welches sich auch im Netzwerkbereich behaupten kann. Dabei wird keinster Weise direkt Code von anderen OS verwendet, vorallem keine Bootloader wie z.B. Grub! Vielmehr wird deren Funktionsweise analysiert. Der Kernel, besser gesagt das Kernel-System von AiCOS wird keines im Sinnes der Definition eines Kernels sein, sondern vielmehr ein Systemkern aus einer modularen Ansammlung mehrere Mikrokernels.