Eigenes OS?
-
Dieser Thread wurde von Moderator/in Marc++us aus dem Forum Assembler in das Forum Projekt: OS-Development verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Wir möchten PrettyOS mittelfristig mit einem USB-Treiber ausstatten, da USB das moderne Bus-System ist. Hier ein Hinweis (aus dem IRC) von XanClic, wie man hierbei vorgehen könnte:
So, wenn ihr also unbedingt USB haben wollt. Ihr schreibt zuerst mal einen PCI-Treiber, der die Geräte auflisten kann und die USB-Host-Controller rausfindet. Dann lest ihr euch bei Wikipedia und in der OS-Dev-Wiki über USB ein.
Dann könnt ihr euch die Spezifikationen (OHCI, UHCI von den Hardwareherstellern bzw. s. Links bei WP; USB 2.0 von usb.org, ebenso die Massenspeicherspezifikation (Bulk only)) runterladen und anschließend damit einen hübschen Treiber schreiben.
-
Tobiking postete im bisherigen Google Groups Forum folgenden grundlegenden Beitrag, den ich für weitere Diskussionen nun hierher transferiere:
Ich habe noch ein paar Punkte die meiner Meinung nach geklärt werden
sollten bevor man groß anfängt Code zu schreiben. Das betrifft den
generellen Aufbau (Buildsystem etc.) und auch den Code selber, um
nicht später alles umschreiben zu müssen sobald sich etwas ändert. Im
IRC ist meist nicht die Zeit etwas größer zu Diskutieren, daher fang
ich das mal hier an.Zum Buildsystem:
- Wie im IRC auch kurz erwähnt denke ich sollte man den ganzen Build
Prozess auf Makefiles umstellen. Ich sehe keinen Vorteil darin für den
Bootloader .bat dateien zu nehmen. Ob es elegant ist die Makefiles
aufzuteilen oder eine große zu haben kann man dann noch überlegen
- Das Erstellen des Kernels sollte auch leicht unter Linux machbar
sein. Mit einem zweiten Makefile oder mit einem include dürfte es
eigentlich einfach machbar sein das es auf den meisten Linux systemen
problemlos funktioniert.Zum Code:
- Verschiedene Architekturen sind ja erstmal nicht angedacht, aber man
könnte trotzdem zumindest bei den Typen etwas Abstraktion einführen.
Dann wird statt unsigned int z.B. uint32_t oder u32 verwendet. Benutzt
man irgendwann einen anderen Compiler oder eine andere Architektur (64
Bit) kann man das mit einem typedef korrigieren. Bei den meisten
Strukturen kommt es ja genau auf die Größe an. Der gcc hat dafür sogar
einen Standard Header (stdint.h), den man ohne weiters nutzen kann. Da
gibt es auch noch ein paar andere Header die man nutzen kann und vor
allem Compiler spezifische Konstanten oder Macros enthalten.
- Struktur der Header. Zurzeit gibt es soweit ich gesehen habe einen
Header, der alles andere includiert. Das könnte irgendwann sehr
unübersichtlich werden. Ansonsten überlegen wie man die Header
ordentlich benennt. Mir ist da die Idee gekommen (und habs bei tyndur
ähnlich gesehen) das man sich an den C Standard orientiert.
Letztendlich schreibt man viele Funktionen die exakt so im C Standard
sind. Also kann man die Header auch angleichen.
- Naja Codestil allgemein ist nicht Lebensnotwendig aber schon eine
tolle Sache. Zeichensatz, Einrückung, ein paar Grundlegende Sachen
sollte man schon festlegen.Mir fällt mit der Zeit bestimmt noch einiges ein. Das ist aber erstmal
alles was mir so gerade einfällt.Zu guter letzt habe ich einfach mal mein Bastel OS hochgeladen in dem
ein paar der Punkte beachtet habe. Ich bin noch nicht so weit gekommen
und es hat an vielen Stellen noch Probleme, aber kann vielleicht die
ein oder andere Idee geben. Zu finden ist es unter:
-
Tutorial, Teil 3, Absatz über Abschnitt "FAT12 - Filesystem der Diskette":
VFS/Initrd wird in 0.1.0091 zum Laden der Shell umgangen, bis der Schwachpunkt (...) bitte ich um entsprechende Information.
Ist das hier geschilderte Problem noch aktuell?
-
Nein, dank ausführlicher Tests mit Cuervo und Unterstützung seitens PorkChicken im Low-Level-Forum wurde dieses Problem lokalisiert und gelöst.
-
[i]Aktuelle Arbeiten:
...
Ich habe diese Übersicht nach "Übersicht über PrettyOS (...)" verschoben.
-
Dies ist ja der Hauptthread, der meinen Einstieg in das "OSDEV" begleitet. Daher möchte ich mich hier sehr herzlich bei allen bedanken, die die bisherigen Gehversuche in die Welt des Kernels, der Treiber und des User-Spaces engagiert und tatkräftig unterstützen, sei es durch kleine Hilfestellungen, Hinweise, Diskussionen, Tests, eigene Experimente, kleine Aufsätze sowie Sourcecode. Ein funktionierendes OS ist die Summe vieler kleiner Schritte und Erkenntnisse. Ich wünsche diesem Subforum und unserer kleinen Gruppe um PrettyOS weiterhin viel Spaß, interessante Diskussionen und gutes Gelingen bei allen Vorhaben.
-
Den Helfern, Freunden und Gönnern dieser Gruppierung um das Thema OS-Development am Beispiel PrettyOS möchte ich aufs Herzlichste danken. Euch allen und euren Familien ein frohes und besinnliches Weihnachtsfest und einen erfolgreichen Start in das Jahr 2010!
-
Da es heute gelungen ist, das Zusammenspiel von PCI, EHCI und USB 2.0 fehlerfrei zu betreiben, ist es an der Zeit diesen Thread mal wieder "auszupacken". Für mich ist das der Beweis, dass man vieles (nicht alles) bewirken und erreichen kann, wenn man es wirklich will und dran bleibt.
-
Nachtrag: der wirkliche Durchbruch bei USB2 MSD/SCSI fand in der zeit vom 11.05. zum 13.05. statt durch einen Versuch und Hinweis von +gjm+, der diesen Thread und das Projekt von Anfang an wohlwollend verfolgt hat. Ich kann nur hoffen, dass +gjm+ uns auch weiterhin treu verbunden bleibt.
-
Weiterer Meilenstein:
Heute konnten Files von verschiedenen usb-Sticks (512 MB FAT16, 1 GB FAT16, 4 GB FAT32, 16 GB FAT32) per FAT16/32-Filesystem aufgespürt (root dir) und von usb MSD mittels SCSI command "read(10)" in den Speicher geladen (FAT, data area) werden. Damit hat die Floppy Disk (FAT12) als zentrales Speichermedium ausgedient.
-
Der "Meilenstein" konnte ausgebaut werden: rev. 476: http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-start-is-490-and-sid-is-e7938c7851b1351fd67c91242b76cae3.html
ttt.elf (unser tic-tac-toe) vom usb-stick (mit FAT16 oder FAT32) wurde geladen und ausgeführt.
-
Aber bis es auch mit Fileeinträgen jenseits des ersten Clusters in der root dir ging, dauerte es dann doch noch etwas.
-
Meilenstein:
Heute haben MrX und ich es in einem tollen team work geschafft, mit3:\ttt elfvon einem usb-stick ttt zu laden und zu starten.
-
Nun kann man von Floppy Disk Device und USB Mass Storage Device laden. Der Device Manager hat an Abstraktionsgrad und Mächtigkeit gewonnen.
"1:\ttt.elf" (bei vorhandener Floppy sogar mit "ttt.elf")
Der device manager ist nun in seinen Grundzügen realisiert und läuft gut.
Nun kann man von Floppy oder usb MSD mit 1:/ttt.elf (durchgezählte angeschlossene Partitionen) bzw. A:/pqeq.elf eine Datei laden und starten.
A: ist die sogenannte Port-Ansprechweise
Ports sind bei uns: FDD, RAM, usb-slots
Disks sind bei uns: FloppyDisk, RAMDisk, usb-stick
Partitionen sind z.B. FAT12/16/32-Partitionen darauf. Wir zählen die Ports mit A,B,C, ... und die Partitionen mit 1,2,3,...Wir haben also drei Ebenen:
- die "Slot"-Ebene, das ist die feste Hardware: RAM, FDD, EHCI-Port
- das eingeschobene Wechselmedium: RAMDisk, FloppyDisk, usb-MassStorageDevice
- die Partition, die wir mit Namen und Serial kennen: part->serial
-
... und 14 Tage später trauen wir uns, auf usb Mass Storage Devices zu schreiben! Mit einem FAT12-Stick klappt es bereits analog zur Floppy.
FAT16 geht ebenfalls korrekt. Bezüglich FAT32 gibt es noch ein Problem bei vielen bereits vorhandenen Einträgen in der root dir (gelöschte zählen mit). Hier muss im FAT-Modul nachgebessert werden. Aber wie diesen Fehler finden?
-
Durch Zufall ist mir der Fehler beim Code studieren aufgefallen. Es geht eben nichts über Code Review. Da hatte ich eine Zeile testweise ausgeblendet (zum Glück nicht gestrichen), die hatte nun gerade für einige Fälle gefehlt.
-
Meilenstein: Version 0.0.1.0 (Rev. 554)
-
Ein OS (im erweiterten Sinne) besteht nicht nur aus Elementen wie Bootloader, Kernel und Treiber, sondern im Hobby-Bereich auch aus den User-Programmen, die speziell für die API maßgeschneidert wurden. Beispiele sind die Spiele TicTacToe von Mrx und ARROW ATTACK von mir. Der "homo ludens" sucht solche Anwendungen, um sich an den Möglichkeiten der IT zu erfreuen und seine Kreativität zu entfalten. Daher kann ich nur immer wieder ermuntern, unterhaltsame und neuartige Programme für PrettyOS zu schreiben. Die API der Userlib ist noch nicht stabil, aber Programmanpassungen werden sicher kein Problem darstellen, da die API bei ihrem Fortschritt eher verbesserte Möglichkeiten anbieten wird, die das Erstellen erleichtern. Also nix wie ran.
-
Ich denke es ist Zeit für einen OSDev Review bei PrettyOS.
Beginnen wir mit http://wiki.osdev.org/Beginner_Mistakes als Leitfaden.
Wir haben nun über ein Jahr Entwicklung von PrettyOS (sicher weniger als 1 Mannjahr in Summe, denn es ist ja ein Hobby-Projekt neben Arbeit, Studium, Schule). Die Shell funktioniert bestens bisher. Die Roadmap wurde eingehalten: Eigener Bootloader anstelle GRUB, Laden/Speichern USB-Stick mit FAT. Netzwerk musste da halt zurück stehen mangels Developer Ressourcen. Man kann nicht alles gleichzeitg machen. EHCI, USB2 und FAT sind schwere Brocken. Nun kommen die "Manager" und die Schnittstellen. Manche machen es umgekehrt, ich möchte zuerst die Funktionalität sehen, wissen, dass es wirklich "geht".
Wir sind zwei aktive Entwickler, vielleicht werden es ab und zu drei sein, die daran werkeln. Die Aufteilung hat bisher gut geklappt aufgrund der unterschiedlichen Interessengebiete. Aber eine Community von 5-10 Leuten, die daran koordiniert arbeiten, ist Illusion. Das muss man rasch einsehen. Im chat gewinnt man neue Leute, und es erhält die Lebendigkeit, leider geht auch Zeit verloren mit für die praktische Arbeit sinnlosen Debatten. Destruktive Stänkerer muss man leider immer wieder in die Schranken weisen. Ertragen muss man auch die "Idler". PrettyOS hat hier momentan einen guten Mix von Leuten, und es gibt ja auch "virtuelle Hinterzimmer" in den chat-Bezirken, wenn wichtige Dinge im kleinen Kreis zu klären sind.
PrettyOS wurde nie als kommerzielles Projekt geplant, sondern als didaktische Hilfe zum Einstieg in OSDev. Daher auch mein Tutorial von Anfang an, das eher ein Skript/Logbuch für mich selbst war. Ein begleitendes e-book schwebte mir vor. Allerdings braucht das länger als geplant, bis ein Niveau erreicht wird, dass man die Dinge vernünftig ordnen und weiter geben kann. Man muss hier mit sich selbst und anderen geduldig sein. Die Erfahrung, die man selbst macht beim Aufbau eines OS und einer damit zusammen hängenden Community ist umfassend und tiefgehend. Man muss dazu bereit sein. Ansonsten gibt man auf. OSDev ist streckenweise "langweilig" und gleichzeitig fordernd.
GUI und Maus, übrigens auch Sound sind sicher ein interessantes Feld, aber dies hält durch hohe Komplexität eher von wesentlichen Dingen ab. Ist momentan nicht auf der konkreten Roadmap.
Wir schreiben unsere eigenen Programme, vielleicht wird die eine oder andere Anwendung portiert werden, aber das ist zweitrangig.
Die Bezeichnung "PrettyOS" habe ich bereits sehr früh festgelegt, bisher habe ich es nicht bereut. Eine Namensänderung kommt nicht in Frage.
Man kann hier aber nur zu Vorsicht raten. Da hilft nur Intuition.Zwischen C und C++ wird man wohl immer schwanken. Beides ist möglich, wobei ich bisher nur Erfahrung mit OSDev und C habe. Ich würde es gerne probieren ein OS in C++ zu bauen, aber am Wesentlichen ändert es nichts. Man wird sich mit C++ eher isoliert vorkommen, da die Literatur C oder Assembler einsetzt.
Inzwischen verwenden wir ein FAT12-Filesystem in dem verwendeten zweistufigen BL, ein ganz angenehmes aber ziemlich unflexibles Verfahren, wenn man z.B. von ubs-stick booten und nachladen will. Niemand hat die Zeit sich intensiv mit dem BL zu befassen. GRUB muss dennoch etwas warten, wobei wir vorbereitet sein müssen. Der Kernel wächst und wächst.
Linker-Script für den Kernel sein:
OUTPUT_FORMAT("binary") OUTPUT_ARCH(i386) STARTUP(object_files/kernel/kernel.o) SECTIONS { . = 0x00100000; __kernel_beg = .; .text : { __code_start = .; } . = ALIGN(0x1000); .text1 : { object_files/kernel/data.o(.text) } .data : { __data_start = .; *(.data) } .rodata : { __rodata_start = .; *(.rodata) *(.rdata) } .bss : { __bss_start = .; *(.bss) *(COMMON) } __start_cdi_drivers = .; .cdi : { __cdi_start = .; *(.cdi) } __stop_cdi_drivers = .; __kernel_end = .; __end = .; }Fazit: Wir haben den Einstieg ganz brauchbar hingelegt. Nun geht es darum, die Sache rund zu gestalten und sich das Interesse zu erhalten.