Thema: roadmap meines kernels - so realisierbar..?

[Gamepower]

hallöle :) erstmal die roadmap:

Code: [Auswählen]

Bereits abgeschlossene Aufgaben:

Vers. 0.0.1
» Einfacher Bootloader (ohne real nutzbares Dateisystem)
» Hardcodet Textausgabe
» Funktion zum Neustart des Computers

Vers. 0.0.2
» Mini- IVT (nur Int 13h | Textausgabe läft nun über diesen Interupt)
» Makros für die Progammiererleichterung
» Erste Kernelmessages

Vers. 0.0.3
» Kleinerer Kernelbugfix (Kernelmessages wurden falsch ausgerichtet)
» Erster Versuch, eines Fat12 Bootloaders einzurichten

Vers. 0.1.0
» Fat12 Bootloader integriert
» Kerneloptimierung (Kernel ist nun ein wenig kleiner, als vorher)
» Vorbereitungen für das Fat12 Dateisystem und Speicherverwaltung

Geplante & kommende Funktionen:

Vers. 0.1.1
» Integration von Dateisystem Funktionen (lesen, schreiben & Ausführen von Dateien & Programmen) | Fat12 Dateisystem- Treiber
» Einrichtung der benötigten Software- Interupts
» Erster Teil der Speicherverwaltung

Vers. 0.1.2
» Ausgabe von Textdateien, bzw. vergleichbares mittels der Dateisystemfunktionen

Vers. 0.1.3
» Einfügen eines Speichermanagers - Vorbereitung(en) für den Protected Mode

» Vorbereitungen für die (erste kleine) Shell
» Teil 1 der API integriert

Vers. 0.2.0
» Erster Testrelease für die Öffentlichkeit
» 24h Langzeit- Test
» Ggf. Kernelbugfix

Vers. 0.2.1
» Falls Notwendig: Kernelbugfix
» Minimale Shell
» Ggf. Fat12 Dateisystem- Treiber Bugfix

Vers. 0.2.2
» Ausbau der minimalen Shell oder neue Shell
» Texteditor
» Ggf. Kernelbugfix

Vers. 0.3.0
» 2. 24h Langzeit- Test
» 2. Testrelease
» Teil 2 der API
» Ggf. Kernelbugfix

Vers. 0.3.1
» Ausbau des Texteditors, bzw. neuer Editor

Vers. 0.4.0
» (feste) Integration erster Anwendungen - darunter den Editor, Taschenrechner (bzw. ähnliches Programm), Datum- / Zeitanzeige & erste portierte Anwendungen
» 24h Langzeit- Test
» Teil 3 der API
» Ggf. Kernelbugfix

Vers. 0.5.0
» Erneuter Testrelease für die öffentlichkeit
» 24h Langzeit- Test
» Vorerst letzter Teil der API
» Ggf. Kernelbugfix

Vers. 0.6.0
» Ggf. weiter Programme » Ggf. Kernelbugfix

Vers. 0.7.0
» Phase 1 zum Umstieg in den Protected Mode
» Ggf. Kernelbugfix

Vers. 0.8.0
» A20 Gate fertig
» Weitere Treiber (Dateisystem usw.) für den Protected Mode umgeschrieben
» Tastaturtreiber fertig (für deutsche und englische Tastatur Layouts)
» IPC fertig
» Malloc fertig
» 24h Langzeit- Test
» Ggf. Kernelbugfix

Vers. 0.9.0
» Assembler Compiler portiert, bzw. einen eigenen geschrieben
» 24h Langzeit- Test
» Ggf. Kernelbugfix

Vers. 1.0.0
» Finaler Release
» 72h Langzeit- Test
» Ggf. Kernelbugfix

Das MinOS ist fertig! Hiernach finden nur noch Bugfixes statt, sofern in der Langzeitnutzung Fehler auftreten.
nun meine fragen:

1. kann man die roadmap so umsetzen?

2. ich stecke beim bauen der fat12 treiber fest. um genau zu sein, muss ich die funktionen zum auffinden, lesen, schreiben und erstellen von dateien einbauen. der beispielcode im tutorial 7 ist sehr umfangreich. aber, wie kann ich diesem so anpassen, das er eine textdatei liest und sie dann am bildschirm ausgiebt...

3. wie realisiere ich die speicherverwaltung im rm...? malloc hat dort sicher kein sinn, oder...?

thx in voraus

[chris12]

zu 2. mit der text-datei: du musst erstmal die sektoren in den speicher laden, dann erkennen, dass das überhaupt ne text-datei ist und nicht möglicherweise ein programm und danach einfach ausgeben

[kevin]

Die ersten paar Meilensteine sehen noch recht vernünftig aus, wenn man davon ausgeht, daß am Ende ein DOS-Clone rauskommen soll. Hinterher wird es aber seltsam.

Zuallererst würde ich da mal den Umstieg auf PM bei 0.7.0 anmerken. Das ist Blödsinn. Entweder du machst ein RM-System oder ein PM-System. Von Anfang an. Umstellen ist nicht drin, das läuft auf einen kompletten Rewrite raus. Wenn du am Ende ein PM-System willst, fang gleich damit an, mit allem anderen tust du dir keinen Gefallen.

Dann finde ich etwas seltsam, daß du schon früh in der Roadmap einen Haufen Anwendungen schreiben willst, aber malloc() erst in der 0.8.0 kommen sollte. Speicherverwaltung ist nicht ganz so unwichtig, das könnten Anwendungen gelegentlich gebrauchen...

Bugfixes würde ich nicht bei bestimmten Versionen erwähnen, die macht man halt, wie die Bugs gerade auffallen. Und wie ist das mit den Langzeittests zu verstehen? Soll das System diese Zeit einfach nur rumstehen und hinterher noch leben oder willst du da irgendwelche Tests laufen lassen?

[Gamepower]

zu 2. mit der text-datei: du musst erstmal die sektoren in den speicher laden, dann erkennen, dass das überhaupt ne text-datei ist und nicht möglicherweise ein programm und danach einfach ausgeben

das währe der nächste punkt... aber erstmal wüsste ich gerne, ob ein...:

Code: [Auswählen]

db "test     txt"
ausreicht, um den namen der quelldatei "vorhalten" zu können...

---

ich glaube man merkt schon, dass ich ne zeitlang kein kontakt zu asm usw. hatte...

---

Und wie ist das mit den Langzeittests zu verstehen? Soll das System diese Zeit einfach nur rumstehen und hinterher noch leben oder willst du da irgendwelche Tests laufen lassen?

es soll schon reale tests stattfinden. um es kurz zu machen: ich will mit den, noch zu bauenden, apps den kernel fordern.. manche fehler findet man ja erst beim längeren tests einer software... oder, wenn bestimmte ereignise auftreten. also muss man halt etwas zeit investieren. die zeitlichen angaben sind so zu verstehen: XX stunden intensiver beschäftigung mit der software. absichtliches herbeiführen bestimmter zustände usw...

zu deinen anderen fragen:

die malloc() will ich paralel zu dem rest bauen... ums kurz zu machen: ich will die malloc() so bauen, das ein programm welches 8kb benötigt, auch 8kb in einem zu bekommt, anstatt 2x 4kb wie es im forum oft vorgeschlagen wird. aber, das ist nur eine idee. wie ich die fertige malloc() am ende stehen habe, muss ik erst testen...

was dem pm angeht, so wird es da eine paralele entwicklung geben.. aus dem MinOS wird, wohl gemerkt erst sehr viel später, ein os hervorgehen, welcher auf meinem guten alten 486er das dos ersetzen wird. das ganze soll auch eine gui beinhalten und mehr als 1mb ansprechen können (der kleine hat 16mb ram ). ich baue mir also soetwas, wie ein ersatz für dos und win3.11... und, ja man könnte etwas anderes nehmen. aber, das währe ja zu einfach

[bitmaster]

Darf ich dir einen guten Tipp geben? Das wird so nichts. *duck*

 

bitmaster

[kevin]

Immerhin hat er zu den Versionsnummern kein Datum geschrieben. Mit ein paar Rewrites ist es zwar immer noch nicht sinnvoll, aber gehen könnte es schon irgendwie.

[bitmaster]

Immerhin hat er zu den Versionsnummern kein Datum geschrieben. Mit ein paar Rewrites ist es zwar immer noch nicht sinnvoll, aber gehen könnte es schon irgendwie.

Irgendwie gehen könnte selbst ein Wurm, wenn er nur Beine hätte. 

[Gamepower]

Immerhin hat er zu den Versionsnummern kein Datum geschrieben.

das ist pure absicht, das es kein release datum gibt. ich bin noch am lernen, was os codung angeht. dazu kommt, das ich beruflich zeitlich etwas knapp bin, und noch andere projekte habe..

Mit ein paar Rewrites ist es zwar immer noch nicht sinnvoll, aber gehen könnte es schon irgendwie.

das es kappen kann, denke ich auch.... mal sehen, wann ich etwas brauchbares zusammen habe, das man als os bezeichnen kann...

[kevin]

Wie gesagt, es wird mit wesentlich weniger Aufwand klappen, wenn du von Anfang an Protected Mode machst.

[Gamepower]

Wie gesagt, es wird mit wesentlich weniger Aufwand klappen, wenn du von Anfang an Protected Mode machst.

mag schon sein.... aber, im rl kann ich bios funktionen nutzen. im pm muss ich mir die funktionen selbst schreiben...

ich denke, ich sollte mal ein geh- versuch im pm machen und dann abwägen, was in meinen augen mehr aufwand erfordert...

[FreakyPenguin]

Alternativ könntest du auch einfach den Leuten hier, die das teilweise schon länger machen etwas glauben.

Klar musst du im RM etwas weniger machen, doch der RM hat auch ein paar nachteile, und ein Umstieg vom RM in den PM bedeutet halt einfach Neuschreiben. Und bei den RM-Dingen wirst du auch weniger schnell Hilfe finden, da sich die meisten nich damit rumschlagen mögen, auch wird es im RM etwas schwieriger eine vernünftige Hochsprache zu finden, und ASM ist halt für grössere Dinge nich so das Wahre.

[kevin]

Klar musst du im RL etwas weniger machen, doch der RL hat auch ein paar nachteile

Du hast ein RL?

Ich glaube, zum Thema braucht man nicht mehr viel zu sagen, das sieht mir eher zwecklos aus. Wer aus den Erfahrungen anderer nicht lernen will, muß sich eben selbst die Finger verbrennen.

[Gamepower]

so, ich habe mir die tyndur sourcen näher angeschaut... das schaut, im vergleich zum spagetiecode bei asm, leichter zu programmieren aus.

daher mal diese fragen:

kann ich mit dem fat12 bootloader von teejay ein in c geschriebenen kernel (z.b. den aus dem c kernel tutorial) booten, oder muss ich zwingend mit grub arbeiten. grub erleichtert natürlich die programmierarbeit, in dem er verschiedenbe funktionen bereits mitliefert... aber, ich möchte gerne soviel wie möglich aus eigener hand einbringen.

wo finde ich tutorials für die folgenden sachen - also malloc; lesen,schreiben und ausführen von dateien/ programmen usw... also eigendlich so alles grundlegende, was ein kernel tun muss...

[bluecode]

kann ich mit dem fat12 bootloader von teejay ein in c geschriebenen kernel (z.b. den aus dem c kernel tutorial) booten, oder muss ich zwingend mit grub arbeiten. grub erleichtert natürlich die programmierarbeit, in dem er verschiedenbe funktionen bereits mitliefert... aber, ich möchte gerne soviel wie möglich aus eigener hand einbringen.

Glaub uns, du möchtest keinen Bootloader schreiben. Es bringt einfach nichts, sondern führt eher zu Frickeleien.
Aber generell kann man das natürlich schon. Den Bootloader von TeeJay kann man sicher auch verwenden, wenn man darauf achtet, was genau der macht und seinen kernel daran anpasst (Adresse wohin geladen wird, Dateiformat des Kernels, wie groß darf er maximal sein, ...).

wo finde ich tutorials für die folgenden sachen - also malloc

Code: [Auswählen]

char* end_of_kernel; // = zB 0x200000
void* malloc(size_t x)
{
  char* tmp = end_of_kernel;
  end_of_kernel += x;
 return tmp;
}
void free(void* p)
{
}
Wäre die einfachste Implementation, danach kommt von der Einfachheit her eine verkettete Liste der freien Speicherbereiche. Ansonsten gibts natürlich open-source Implementierungen, da hab ich erst kürzlich in einem von bitmasters Threaads eine kleine Liste gepostet.

lesen,schreiben

* BIOS-Interrupt (13 dürfte es glaub ich sein) fürs lesen/schreiben im Bootsektor von Sektoren
* Dokumentation des verwendeten Dateisystems

und ausführen von dateien/ programmen usw

* Dokumentation des verwendeten Dateiformats

Links/Artikel gibts in unserem Wiki (hier vor allem der OSDev für Einsteiger Artikel!) oder auch in dem von www.osdev.org (englisch). Ansonsten gibt Soforthilfe im Channel #lost auf euirc (siehe wikiartikel zu IRC).

[matheguru]

Also ich würde dir empfehlen nicht den code aus Ausgabe 7 insofern zu ändern, dass er auch noch Dateien anzeigt, das sollte schon ein anderses Programm übernehmen, dass dann über die Dateisystemfunktionen die Dateien in den Speicher liest. Und schreib am besten gleich ein FAT32 Systemtreiber damit kannst du hinterher auch noch größere Partitionen auf Festplatten lesen, falls du mal so weit kommen möchtest. Ich kann dir dieses Tutorial nur empfehlen, schon allein wegen dem besseren verständniss über FAT DS erik.milsch.googlepages.com/FAT32_Erik_Milsch.pdf

[Gamepower]

ich denke, ich werde mir einige quelltexte der anderen hobby betriebssysteme ansehen und davon lernen. ich habe mir auch noch das buch "c für pc´s" gekauft. darin sind auch einige dinge, darunter auch malloc, beschrieben...

[bluecode]

[...] darin sind auch einige dinge, darunter auch malloc, beschrieben...

Darf ich ganz kurz fragen, ob du die konkrete Implementation (das bezweifle ich) oder wie man es benutzt meinst? Ich dachte bei deiner Frage oben nämlich eher an ersteres...

[Gamepower]

[...] darin sind auch einige dinge, darunter auch malloc, beschrieben...

Darf ich ganz kurz fragen, ob du die konkrete Implementation (das bezweifle ich) oder wie man es benutzt meinst? Ich dachte bei deiner Frage oben nämlich eher an ersteres...

wenn du magst, stelle ich mal ein beispielcode, welche die malloc ermöglichen soll, hier rein. vieleich kannst du mir dann sagen, ob der code für mein projekt verwertbar ist...

[ChristianF]

[...] darin sind auch einige dinge, darunter auch malloc, beschrieben...

Darf ich ganz kurz fragen, ob du die konkrete Implementation (das bezweifle ich) oder wie man es benutzt meinst? Ich dachte bei deiner Frage oben nämlich eher an ersteres...

wenn du magst, stelle ich mal ein beispielcode, welche die malloc ermöglichen soll, hier rein. vieleich kannst du mir dann sagen, ob der code für mein projekt verwertbar ist...

Du kannst den Beispiel-Code ja mal posten, falls er nicht zu lange ist. Interessieren würde es mich ja schon...