Um den Speicher zu verwalten, muss der Kernel doch eine Liste der allokierten Elemente habenDer Kernel muss primär eine Liste der freien, physikalischen Speicherseiten haben. Diese Liste könnte man zB. als Stack (Das ist nicht die einzige Möglichkeit, aber so [ähnlich] habe ich es in lightOS gemacht) implementieren, wobei man zum Allozieren von Speicherseiten einfach von diesem Stack Einträge (Das sind bei mir physikalische Adressen einer 4kb Speicherseite) runterholt und zum Freigeben diese Adresse wieder drauflegt. Das tolle daran ist, dass man den Speicherbereich, den man zum Speichern dieses Stacks braucht, nach und nach (je kleiner der Stack wird) mit freigeben kann.
[...] um zu erkennen, was schon weg ist und zu welchem Task der Bereich gehört, oder nicht?Das steht doch in den Page-Tables/-Directories dann, dass heißt man könnte es prinzipiell auch dort auslesen.
Angenommen ein großes Programm benötigt 12 MB Speicher.Der Overhead sind da 3Page-Tables (also 12kb), wenn man davon ausgeht, dass man das allozierte wirklich nur in den Page-Tables/-Directories speichert, richtig? Das erscheint mir wirklich nicht so viel, wenn man es mit der Programmgröße von 12Mb vergleicht.
Wäre es ratsam den ganzen Arbeitsspeicher durchgängig von 1 MB aufwärts zu nutzen? Oder soll ich mein verschiedenes Zeugs noch irgendwo zwischen GRUB und dem ganzen VGA-Zeugs ansiedeln? Lohnt sich das?Die grub memory-map bzw. die BIOS memory map (das ist exakt das selbe) sagt dir genau welche Bereiche frei/belegt sind.
In der Multibootspekifikation wird die Größe des verwendbaren Arbeitsspeichers ja in mem_lower und mem_upper unterteilt. Beginnt der obere Arbeitsspeicher dann bei 1 MB genau und der untere Teil bei 0? Ja, oder?Jop, genau. Aber die Zahlen sind nicht so richtig aussagekräftig. Es gibt Systeme, die haben ein Speicherloch zwischen dem 15ten und dem 16ten MB. Teilweise sind auch ACPI Tabellen im RAM. Am besten deine Speicherverwaltung mit oben erwähnter memory-map initialisieren.
+-------------------+
-4 | size |
+-------------------+
0 | base_addr_low |
4 | base_addr_high |
8 | length_low |
12 | length_high |
16 | type |
+-------------------+
Das ist wohl eine sehr wichtige Information aus den GRUB-Informationen. Allerdings verstehe ich nicht, weshalb die Adressierung mit 64 Bit geschieht?! Überall gibt es 32-Bit-Adressen, nur hier nicht, was läuft da schief?Man wollte halt dann doch mal mit der Zeit gehen und eben ein bisschen mit PAE und 64bit kompatibel sein.
Desweiteren verstehe ich irgendwie nicht, weshalb die Adressierung bei -4 beginnt. Was soll das? Was bedeutet das size da oben?Du kriegst einen Pointer auf die memory-map an der Adresse (pointer - 4) steht die größe der mem-map. Die Einträge sind dann von pointer bis (pointer + size).
Durch das aktivierte Paging gibt es nur noch virtuelle AdressenDas ist falsch. Du kannst nur noch über die Indirektion des virtuellen Adressraum auf den physischen zugreifen, aber "da" ist letzterer schon noch. Du musst überlegen wie du an den physischen rankommst, aber du kannst ja mappen wie du willst insofern ist das kein Problem. Das einzige was 0xd00f ist, ist dass du an das Page-Directory und an die Page-Tables rankommen musst um zu mappen, deshalben müssen diese von Anfang im virtuellen Adressraum gemappt sein.
aber mein toller Blockallokator soll doch den physikalischen Arbeitsspeicher aufteilen. Was ist da zu tun?Daran ändert sich mit Paging garnichts (wenn ich jetzt mal Blockallokator als physisches Speichermanagement interpretiere).
dass aller physikalischer Speicher als ganzes Beispielsweise an das Ende des virtuellen Adressraums gemappt werden kann. Das ist natürlich ziemlich uneffizient.Wie oben gesagt, du brauchst eigentlich nur die Page-Tables und das Page-Directory ständig gemappt, aber es ist halt teilweise auch nicht doof "einfach so" auf den physischen Speicher zuzugreifen und deswegen den ges. physischen Speicher zu mappen. Aber ist wohl im protected-mode mittlerweile vorbei... aber im longmode macht es finde ich wieder Sinn.