Thema: Vorgehensweise der Implementationen

[woigl]

Nun mein C-Kernel laeuft mal soweit ganz gut...

In welcher Reihenfolge wuerdet ihr nun die Dinge wie Multithreading, Keyboard, Harddisk Driver usw. implementieren?

Bzw. was ist ueberhaupt mal als Basis sinnvoll...

Sollte man sich an den Posix Standard halten? Wenn ja wo bekommt man eine schoene Uebersicht darueber?

[Legend]

Erstmal: Soll dein Kernel Monolitisch, Micro, Hybrid oder Exo werden?

Zu Posix: Wenn du noch ein weiteres (so-gut-wie)-Unix produzieren willst, ja, musst du praktisch sogar, ansonsten würde ich doch von diesem Standard abraten. Wobei etwas wie Cygwin nicht ganz unpraktisch wäre, aber ich würde mir nicht von dem Posix-Standard mein Design ruinieren lassen.

[woigl]

Also irgendwie hast du vollkommen Recht - die Frage ist nur wie sieht es dann mit der Portierung anderer Anwendungen auf mein System aus?

Ebenfalls stellt sich dann auch noch die Frage ob ich auch einen eigenen Compiler bauen muß, da ja der GCC unter GLIBC läuft... oder?

[Legend]

Tja, ich frage mich auch warum es beim gcc so problematisch ist ihn unter auch nur unter Cygwin, DJGPP oder MinGW zu bauen.
Für einen C-Compiler sollte man doch eigentlich mit C99-Standard Funktionen auskommen - und dann könnte man den auch mit jeder beliebigen C99-kompatiblen C Bibliothek bauen.

[woigl]

Tja, ich frage mich auch warum es beim gcc so problematisch ist ihn unter auch nur unter Cygwin, DJGPP oder MinGW zu bauen.
Für einen C-Compiler sollte man doch eigentlich mit C99-Standard Funktionen auskommen - und dann könnte man den auch mit jeder beliebigen C99-kompatiblen C Bibliothek bauen.

sollte man... ...Also C99 ist der Ansi-C Standard - gibts da wo eine Page wo man die ganzen zu implementierenden Befehle für diesen Standard einsehen kann?

[SSJ7Gohan]

Um Prozesse, Treiber usw. vernünftig verwalten zu können, brauchst du erstmal ein Memory Management.

Es gibt Systeme, die das Memory Management ausserhalb des Kernels in einem eigenen Prozess verwalten, das halte ich aber nich für sinnvoll, da du überhaupt erst Speicher brauchst, um die Prozesse darein laden zu können.

Das Prozess Management/den sheduler würde ich auch in den Kernel integrieren, es nur zusätzlichen Aufwand erzeugt, den scheduler als eigenen Prozess zu implementieren.

Was du danach machst hängt von deinem OS ab. Ich würde es für sinnvoll halten, erstmal einen Treiber für das Bootlaufwerk zu schreiben, und dann andere Treiber für Keyboard, Maus, wenn du willst auch Grafik usw. zu basteln.

Das ganze ist aber nur ein Vorschlag, du kannst dein OS auch komplett anders strukturieren.

[woigl]

Ja Grafik und so sollte auch mal kommen, aber daran denke ich noch nicht!!

Was genau versteh man unter Memory Management, was beinhaltet das alles, gibts da ein Tutorial??

[SSJ7Gohan]

Naja, mit Memory Management meine ich Funktionen, um dynamisch Speicher zu allocaten, sowie die das Paging zu verwalten.

Wie du das einbaust, ist eigentlich ganz dir überlassen, du kannst die komplette malloc() Funktion in den Kernel einbauen, oder nur systemcalls bereitstellen, um Pages zu allocieren und zu mappen.

[woigl]

Naja, mit Memory Management meine ich Funktionen, um dynamisch Speicher zu allocaten, sowie die das Paging zu verwalten.

Wie du das einbaust, ist eigentlich ganz dir überlassen, du kannst die komplette malloc() Funktion in den Kernel einbauen, oder nur systemcalls bereitstellen, um Pages zu allocieren und zu mappen.

ja ich dachte schon den malloc lt. Ansi C zu implementieren - aber trotzdem auch die Systemcalls bereitstellen - oder ist das nicht gu?

[Legend]

Du wirst sowieso zwei malloc's haben. Eines für den Kernel und eines noch mal in deiner C Lib. Warum? Der Kernel kann den Anwendungen nur auf 4kb genau Speicher geben, daher wirst du das selber nochmal unterteilen müssen.

[woigl]

Du wirst sowieso zwei malloc's haben. Eines für den Kernel und eines noch mal in deiner C Lib. Warum? Der Kernel kann den Anwendungen nur auf 4kb genau Speicher geben, daher wirst du das selber nochmal unterteilen müssen.

Okay ich denke das versteh ich mal soweit - also ist die C Lib sogesehen unabhaengig zum Kernel...

[Legend]

Nun ja, sie baut auf dem Interface vom Kernel auf. Muss aber trotzdem noch etwas tun! Also sie ist nicht nur ein Wrapper.