ChangeLog

[Dirty Oerti]

Nur um euch mal auf dem neusten Stand zu halten:

Ich komm recht gut voran mit meiner "Neuimplementierung", und sie gefällt mir auch viel besser als die alte.
Ich arbeite ja mit git, von dem ich in dem Zusammenhang sehr angetan bin.

"Laufen" tut noch nichts, noch nichtmal kompiliert werden kann der "neue" Kernel.
Da wird dann wohl bald cmake ins Spiel kommen...

[Dirty Oerti]

Nur mal wieder ein kleines Update:

Ich hab die "Bootreihenfolge" jetzt angepasst.
Nach dem Booten wird jetzt nicht wie früher, erst GDT/IDT aufgesetzt sondern sofort mit der Speicherverwaltung begonnen
Die Speicherverwaltung stützt sich ab jetzt auch auf die MMAP, die mir von GRUB bereitgestellt wird (um z.B. defekte Speicherbereiche zu umgehen)

Außerdem denke ich im Moment über eine Möglichkeit nach, die Kernelfunktionen, die später aus dem USERSPACE aufrufbar sein sollen soweit wie möglich ans Ende des Speichers zu schieben.
Wahrscheinlich wird der eigentliche Kernel dadurch recht klein bleiben, denn diese Funktionen werde ich wohl in Module auslagern, die von GRUB mitgeladen werden.
So kann ich die Module einfach beim Initialisieren des Pagings ans Ende des (virtuellen) Speichers mappen.

Nochwas ist "anders": Ich hab mich jetzt doch dazu entschlossen, "eigene" Typen zu verwenden. Diese eigenen Typen werden in einem eigenen Header definiert und sind im Moment nur die Standardtypen. Das lässt mir aber die Möglichkeit für weitere Änderungen (andere Architekturen etc) offen
Jetzt muss ich gedit nur beibringen, dass es doch bitte UINT INT INT8 INT16 etc auch hervorheben soll

Wie sieht es eigentlch mit dem git-Repo aus?
Also im Moment würde es eh noch nichts bringen, immerhin kann der Kernel immernoch nicht gebootet werden.

[nufan]

Nochwas ist "anders": Ich hab mich jetzt doch dazu entschlossen, "eigene" Typen zu verwenden. Diese eigenen Typen werden in einem eigenen Header definiert und sind im Moment nur die Standardtypen. Das lässt mir aber die Möglichkeit für weitere Änderungen (andere Architekturen etc) offen

Also etwas wie

Code: Alles auswählen

typedef char INT8;

? Ich nehme mal an char ist auf jedem System gleich (wegen ASCII), aber wie definierst du dann INT16?

Jetzt muss ich gedit nur beibringen, dass es doch bitte UINT INT INT8 INT16 etc auch hervorheben soll

Einfach die neuen Typen in /usr/share/gtksourceview-2.0/language-specs/c.lang hinzufügen. Also eben hier einfügen:

Code: Alles auswählen

<context id="types" style-ref="type">
<keyword>_Bool</keyword>
<keyword>_Complex</keyword>
<keyword>_Imaginary</keyword>
<keyword>bool</keyword>
<keyword>char</keyword>
<keyword>double</keyword>
<keyword>float</keyword>
<keyword>int</keyword>
<keyword>long</keyword>
<keyword>short</keyword>
<keyword>signed</keyword>
<keyword>size_t</keyword>
<keyword>unsigned</keyword>
<keyword>void</keyword>
</context>

Getestet hab ichs aber nicht ^^
Vielleicht kannst du auch gleich eine "neue Sprache" erstellen, damit du das Original nicht verändern musst.

[Dirty Oerti]

Um genau zu sein sieht das Original types.h im Moment so aus:

Code: Alles auswählen

// types used in the kernel

#ifndef __KERNEL__TYPES___HEADER____
#define __KERNEL__TYPES___HEADER____



/* integers */
typedef char INT8;
typedef unsigned char UINT8;
typedef short INT16;
typedef unsigned short UINT16;
typedef int INT32;
typedef unsigned int UINT32;
typedef long long INT64;
typedef unsigned long long UINT64;

/* floats */
typedef float FLOAT32;
typedef double FLOAT64;
typedef long double FLOAT128;


/* for comfort */
typedef INT32 INT;
typedef UINT32 UINT;



#endif // (__KERNEL__TYPES___HEADER____)

Das soll/kann dann per Maschinenabhängier Defines weiter konfiguriert werden

Danke für den Tipp mit den gedit Highlighting. Ne neue Sprache wirds nicht werden, sonst muss ich die manuell immer einstellen

[Dirty Oerti]

Wie sieht es eigentlch mit dem git-Repo aus?
Also im Moment würde es eh noch nichts bringen, immerhin kann der Kernel immernoch nicht gebootet werden.

Ich dräng mal ein bisschen
Immerhin kann der Kernel jetzt gebootet werden...

Zwar funktioniert das noch nicht automatisch per makefile, aber wenn man sich ein bisschen mit GRUB etc auskennt sollte es kein Problem sein
Wobei: Bald...gehts auch übers makefile.

Was jetzt als nächstes mal ansteht ist eine print Funktion, die ich iwie weggelassen hatte. Zum Kontrollieren, was genau passiert brauch ich die aber
Wenn dann dadurch bestätigt wird, dass meine Speicherverwaltung mittels mmap funktioniert, gehts weiter drann, die IDT und damit auch alle Interupt Routinen festzulegen.
Dann sollten die Pagingfunktionen (die schon vorbereitet sind) folgend und damit dann auch ein (diesesmal nun hoffentlich funktionierendes) Paging in den Kernel einziehen.
Hand in Hand damit geht dann auch die Einführung mehrerer Tasks.

[Dirty Oerti]

Ok, zwar keine wirkliche Verbesserung, aber man sieht jetzt zum ersten mal was nach dem Booten
Dort erscheint ein nettes und freundliches "Fertig" ^^

Unter der Haube (wenn man das so nennen kann) ist aber schon ein bisschen was passiert^^

*edit* 24 Jun 09 23:20

So, jetzt funktionieren (nicht ausführlich getestet, ist aber im Prinzip alter, getesteter Code) GDT,IDT,ISR,IRQs und natürlich die Speicherverwaltung auf phys. Ebene. Wobei es da eine Funktion gibt, mit der ich überhaupt nicht zufrieden bin^^. Die Funktion dient zum Alokieren mehrerer, direkt zusammenhängender Frames und war mit dem gegebenen Suchfunktionen eigentlich nicht zu implementieren. Da werd ich noch was dran rumschrauben müssen

[Dirty Oerti]

Tag

So, nach kurzen Kämpfen funktioniert jetzt auch ein primitives Paging
Als nächstes brauch ich Funktionen, um im laufenden Betrieb Page Directories (und damit Adressräume) wechseln zu können.

[Dirty Oerti]

So

Im git Repo hat sich seit nun etwas längerer Zeit (7 Tage) nichts mehr getan.
Hier, bei mir lokal experimentiere ich im Moment damit, den Kernel auf höhere, virtuelle Adressen zu "verschieben".

Dabei ist es "normalerweise" Gang und Gebe, dass man den Kernelcode an z.B. 3 GB "hinauflinked" und alles darüber nur dem Kernel gibt. Alles darunter gehört dann dem Prozess (dem der aktuelle Addressraum gehört)

Ich möchte das ein kleinwenig anders gestallten: Anstatt den kompletten Code des Kernels in jeden Adressraum zu linken, möchte ich nur ein sehr beschränkten Codeteil dazu hernehmen. Dieser Code dient dann als eine Art "Anruffunktion", mit der der Weg für restliche Arbeiten dann frei gestellt werden sollen.

Sinn ist, dass dem Prozess mehr virtueller Speicher als nur von 0-3GB zur Verfügung stehen sollen
Schwer drann ist: Eine gute Kommunikation hinbekommen. (Irgendwie muss ich dem Kernel mitteilen, das was zu tun ist, der Code im Kernel steht mir aber nicht zur Verfügung)

Mal sehen was draus wird^^

[Dirty Oerti]

Tag

Also ich arbeite jetzt zur Zeit mal wieder an meinem Kernel.
Multitasking ist nun soweit drinnen, nur müssen die Tasks sich im Moment noch einen Adressraum teilen. Das wird sich jedoch ändern, sobald ich einen Task (im Kernel-Adressbereich) habe, der das Mapping verwalten kann. Das an sich ist eigentlich kein Problem. Schwieriger wird die Kommunikation zwischen den Tasks/Prozessen.
Dafür muss ich mir noch was schlaues überlegen, denn davon hängt im Endeffekt ab, wie schnell/sicher/stabil das komplette System laufen kann.

Im Moment stelle ich mir ein nachrichtenbasiertes System vor. Wie genau ich das umsetzen soll weiß ich aber noch nicht. Im Moment bekommt jeder Adressraum (und damit jeder Task) einen eigenen "Kernelbereich", in den er über Funktionen schreiben kann (Nachrichten in den Postausgang legen sozusagen)
Problem an der Sache ist: Wie gebe ich dem Empfänger möglichst schnell Bescheid, dass es eine Nachricht für ihn gibt?

Da die Hauptkommunikation sich auf Systemprozesse beschränken wird (zumindest die, die über das System laufen soll, Interprozesskommunikation ist wieder ein anderer Schuh) dachte ich auch schon daran jedem Task den gleichen Kernelbereich "einzumappen", auf den er dann wiederrum Nachrichten schreiben kann.
Vorteil: Es gibt nur einen Bereich im Speicher, an dem sich Nachrichten befinden können, somit ist die Suche nach Nachrichten deutlich einfacher und schneller.
Problem: Was tun, wenn der Speicher voll ist?

Ihr seht, darüber bin ich mir mit mir selbst noch nicht ganz einig. Über Anregungen würde ich mich also sehr freuen

Achja: Die Aufteilung im Speicher schreitet voran.
Es gibt eine Section .boot, in der sind die Dinge, die sich unbedingt ganz vorne im Speicher befinden müssen (sonst lädt GRUB den Kernel nicht).
Dann die Section .setup, in der Funktionen etc sind, die nur zum Starten gebraucht werden (Die Funktion um die GDT einzurichten wird z.B. nur einmal gebraucht). Wenn der Startzustand mal überwunden wurde, dann wird diese Section aus dem Speicher getilgt, so dass mehr Platz für wirklich wichtigen Code da ist
Und natürlich die .klinked Section, in der der wichtige Kernelcode drinnen ist, auf den jeder Task zugreifen können muss.

Soweit so gut

[cloidnerux]

Problem an der Sache ist: Wie gebe ich dem Empfänger möglichst schnell Bescheid, dass es eine Nachricht für ihn gibt?

Hängt jezt davon ab worum es sich handelt. Wenn der Task(Thread) einen I/O Zugriff straten will, z.B Datei lesen, wäre er doch in einem "Leerlauf", also nimmst du ihn aus der Threadliste und in eine Jumptable für den I/O Treiber, damit er weiß wlechen Thred er aufrufen soll wenn er fertig ist mit Daten laden, so z.B ruft der Thread nur einmal den I/O Treiber auf und nur einmal die Abfrage.
Und für die Interrprozess Komunikation würde mir so spontan eine Queue einfallen. Jeder Thread der etwas von einem anderen will gibt eine Addresse und Befehl an den Kernel, der legt diesen an das Ende der Queue und führt die befehle dann aus.