Midgard Prozesse

[Hansinator]

Guten Tag!

Ich werd jetzt mal hier den anfang eines endgültigen prozess-threads machen ;)
Für alle, die inzwischen an midgard mitarbeiten wollen, und noch nicht ganz genau bescheid wissen, wie prozesse im moment funktionieren, einmal der ist zustand:

Prozesse gibt es nicht in midgard. Noch nicht!!
Es gibt einen scheduler, der ganz nach multitasking manier "prozesse" der reihe nach an die CPU lässt.
Aber prozesse sind in wirklichkeit kernelfunktioenen.
Es werden also quasi einfach nur verschiedene funktionen innerhalb des kernels nacheinander ausgeführt.


Und das sollte zutun sein:

Es müssen eigene speicherbereiche erstellt werden können, in denen die prozesse dann quasi residieren.
Natürlich müssen dann trotzdem erstmal die kernelfunktionen herhalten, weil wir noch keine dateien von der festplatte laden können.
Jedoch ist es aus 32-bit mode sicht schon prozessiger ;)

Ich werde mal versuchen mich in den kram einzulesen, aber versprechen kann ich nicht, da ich stinkfaul und häufig unmotiviert bin..
Trotzdem, jede hilfe ist willkommen.

Falls benötigt, und interesse besteht, können lizer und ich gerne links zu einigen themen die sich damit befassen bereitstellen!

[lizer]

Hmm, ich schreib hier noch dazu, was genau zu tun ist:

1. braucht der Memory Manager eine Funkion, die Speicher für einen Prozesse bereitstellt und anhand dieses Speicherbereichs eine LDT (Local Descriptor Table) für den Prozess erstellt, welche wiederum mehrere Einträge haben kann, und zwar (minimum) einen Eintrag für den Code-Bereich, einen für den Stack und einen für das Data-Segment.
2. muss dann die Prozess-Struktur (struct process) sowie der Schedule und die Trap etwas verändert werden. Anstatt nämlich blöd alle Register zu kopieren können diese einfach auf den lokalen Stack des Prozesses (Stack Segment beschrieben in der LDT (s.o.)) gepusht werden (pusha). Anschließend wird dann einfach der Stack gewechselt, d.h. EBP und ESP werden mit den Stack-Daten eines anderen Prozesses gefüllt. Von diesem Stack werden dann einfach die Register des Prozesses gepoppt (popa) und der Prozess kann weiterlaufen.
3. Muss eine Funktion her, die einen Prozess generiert, d.h. einen Speicherbereich vom MM holt und Standard-Werte für die Register drauf-pusht, sodass beim ersten Aufruf des Prozesses dieser einfach die Werte poppen kann als wäre er schon am laufen (siehe 2.).

Ich hab sicher was vergessen, ich schreib später noch was dazu.

[mgr]

Bei mir ist es so das ich mich in den letzten Tagen mal ein bisschen durch die Midgard Quellen gewühlt habe und feststellen durfte das das ganze doch nicht so schwer ist wie zuerst angenommen.

Ich les' mich auch mal in den Prozesskram mit ein und schau ob ich irgendwo helfen kann, auf mich trifft jedoch selbiges zu wie auf hansinator... stinkfaul und ständig unmotiviert, jedoch würd's mich freuen wenn ich mich bei diesem Projekt ein wenig einbringen könnte.

[Hansinator]

Stichworte hierzu wären LDT und LGDT, also die descriptor tables ;)

[Hansinator]

Wie sieht's eigentlich im moment genau aus?
Wir haben den segmented mode, und der ganze ram ist ein segment, oder?
Ich hab gerade angefangen mir das durchzulesen, und frag mich gerade, was man denn so für ein speichermodell benutzt dann?

Edit:
http://members.tripod.com/protected_mode/prashant/protmode.html?the_id=17#Introduction

[lizer]

GDT = Global Descriptor Table
LDT = Local Descriptor Table
(Eine LGDT (Local Global DT) existiert daher nicht :))

Zur Zeit übernehmen wir einfach nur die Table, die GRUB für uns baut. Wie die genau aussieht, kann man in der GRUB Multiboot Spec. nachlesen (http://www.uruk.org/orig-grub/boot-proposal.html unter "Machine State"). Demnach enthalten alle Segmente Register (CS, DS, ES... SS) Descriptoren für ein und den selben Speicherbereich, der bei 0x0 anfängt und 0xFFFFFFFF Bytes groß ist, also den kompletten Speicher (bis zu 4G) beschreibt.

Gute (aber etwas anspruchsvoller Infos kriegt man in der Intel x86 Doku, die es bei Intel selbst und bei www.osdever.net als PDF gibt. Dort sind alle Register, Flags, Tables usw. genaustens beschrieben. Außerdem wird dort gleich erklärt, welche Register für's TaskSwitching benötigt werden und wie man es macht :)

[Hansinator]

Ich dachte, du hast das task switching schon drin? *g*
LGDT = Load Global Descriptor Table
Das ist n assemblerbefehl ;)
Die intel doku hab ich mir schon gesaugt, trotzdem werd ich bisher nochnicht schlau draus, ob midgard jetzt paging oder segmenting bekommen soll..

[lizer]

Ich dachte, du hast das task switching schon drin? *g*
Ja, aber wie gesagt, nicht 'richtig'. Z.Z. werden einfach nur alle Register gesichert und beim nächsten Start wieder geladen. Außerdem teilen sich alle 'Prozesse' den gleichen Stack (von 0-0xFFFFFFFF :)) usw.


Stichworte hierzu wären LDT und LGDT, also die descriptor tablesHmm, in diesem Context hab ich nicht an LGDT gedacht :)


ob midgard jetzt paging oder segmenting bekommen soll
Beides. Segmente brauchen wir auf jeden Fall, denn irgendwas müssen wir ja in die Segment Register schreiben (DS, CS, ...). Paging kommt später noch dazu, sofern du unter Paging das auslagern von Arbeitsspeicher (Pages) auf die Platte verstehst.

[Hansinator]

Nein, man kann den kram in 2 modi initialisieren soweit ich das verstanden habe.

Paging und segmente.
Einmal ist der arbeitsspeicher halt segmentiert und einmal in pages aufgeteilt.
Das mit dem paging auf platte funktioniert so, wenn eine angeforderte page nicht verfügbar ist, löst die cpu eine exception aus.
Wenn das OS die page irgendwo auf der festplatte hat, dann läd es sie schnell - davon kriegt man dann nix mit - oder es findet die page nicht und das betroffene programm muss beendet werden.

Beides gemischt geht glaub ich nicht.
Segmenting wird in den meisten beispielen genommen, da es einfacher zu implementieren ist.
Falls mir jetzt einer was besseres erzählen will, wär das gut, weil segmenting halt einfacher ist :D

[lizer]

Das mit dem paging auf platte funktioniert so, wenn eine angeforderte page nicht verfügbar ist, löst die cpu eine exception aus.
Wenn das OS die page irgendwo auf der festplatte hat, dann läd es sie schnell - davon kriegt man dann nix mit - oder es findet die page nicht und das betroffene programm muss beendet werden.Stimmt genau, aber warum soll das nicht zusammen mit Segmenten funktionieren. Eine Page ist einfach nur ein Speicherbereich (AFAIK 4K), der vorhanden sein kann oder nicht - oder eben grad auf Platte. So kann zum Beispiel auch das Code Segment aus mehreren Pages bestehen, so muss das OS nicht das komplette User-Programm im SPeicher haben. Um Segmente kommt aber niemand drum rum, das Paging ist einfach nur ein AddOn (unsere User werden sich schön bedanken wenn ihre Programme keine Segment Register (CS, ES, DS, ...) verwenden dürfen).

[Hansinator]

Naja, ich stzütze mich jetzt auf waages wissen, aber ich glaube gelesen zu haben, dass die segment register eh egal sind im 32 bit modus, weils da 2 neue gibt irgendwie, und man eigentlich auch alle register dafür benutzen kann.
Ich guck nochmal, ob beides geht, aber ich glaube die descriptor tables können halt jeweils nur eins describen, paging oder segmenting.
Aber ich les mich nochma mehr darein ;)

[lizer]

Arrgh! Glaub's mir doch einfach! :)

3.2.4. Paging and Segmentation
Paging can be used with any of the segmentation models described in Figures 3-2, 3-3, and 3-4.
Die drei erwähnten segmentation models sind "Basic Flat Model", "Protected Flat Model" und "Multisegment Model", wobei wir das dritte benutzen:

3.2.3. Multisegment Model
A multisegment model (such as the one shown in Figure 3-4) uses the full capabilities of the segmentation mechanism to provided hardware enforced protection of code, data structures, and programs and tasks. Here, each program (or task) is given its own table of segment descriptors and its own segments. The segments can be completely private to their assigned programs or shared among programs. Access to all segments and to the execution environments of individual programs running on the system is controlled by hardware.
EDIT: Und damit mal endgültig geklärt ist, was hier genau mit Paging gemeint ist:
When paging is used, the processor divides the linear address space into fixed-size pages (generally4 KBytes in length) that can be mapped into physical memory and/or disk storage. When aprogram (or task) references a logical address in memory, the processor translates the address
into a linear address and then uses its paging mechanism to translate the linear address into a corresponding physical address. If the page containing the linear address is not currently in physical memory, the processor generates a page-fault exception (#PF). The exception handler for the page-fault exception typically directs the operating system or executive to load the page from disk storage into physical memory (perhaps writing a different page from physical memory out to disk in the process). When the page has been loaded in physical memory, a return from the exception handler causes the instruction that generated the exception to be restarted. The information that the processor uses to map linear addresses into the physical address space and to generate page-fault exceptions (when necessary) is contained in page directories and page tables stored in memory.

[Hansinator]

Aah, super, danke :D
Das Intel ding wollte ich mir als nächstes durchlesen, denn die texte/tutorials die man so auf osdever findet sind irgendwie recht unnütz, wenn man jetzt tatsächlich den speicher programmieren will.