Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Beiträge anzeigen
1
Lowlevel-Coding / Qemu-Bug und Ideen
« am: 03. October 2012, 21:44 »
Hallo, ich hab` da mal ein paar Fragen:
Ich habe jetzt einmal eine eigene physische Speicherverwaltung geschrieben, die auch soweit alles macht, wie ich es will,
nur die Initialisierung funktioniertr nicht, ich hatte immer einen Nullpointer zurückbekommen, es wird phys_free(0) aufgerufen.
Diesen Fehler konnte ich nun dadurch beseitigen, dass ich
Wirklich frei ist er nicht, denn Qemu schmiert ab, wenn ich nach 0 etwas schreibe (Nullpointer sind auch einfach böse
)
Dann habe ich noch eine Frage bezgl. Modulen:
Würde es funktionieren, wenn am Anfang eines Modules (als flache Binary wahrscheinlich) eine Funktion ist, die einen Kernel-Interrupt aufruft,
die einen Pointer auf eine Tabelle mit Kernel-Funktionen zurückgibt (darunter auch eine, die das Modul aufruft, um sich selbst zu registrieren)?
Oder kann es sein, dass ich gerade das Modulsystem von Linux beschrieben habe?
Eine Idee, wie man eine Speicher-/Heapverwaltung umsetzen könnte, habe ich auch noch:
Am Anfang ist der ganze Speicher ein Bereich, am Anfang jedes Bereiches liegt ein uint32_t (vllt. überdimensioniert),
der die Größe des Bereiches angibt und ob er frei/belegt ist.
Will man nun zuerst Speicher allozieren, so setzt man den Anfang des ersten freien Bereiches, der groß genug ist,
die Größe des belegten Platzes und dass er belegt ist, geschrieben und hinter diesen Bereich die Größe des restlichen freien Speichers.
Um einen Bereich wieder frei zu geben, markiert man diesen wieder als frei und verbindet ihn wenn möglich mit dem freien Speicher dahinter.
Damit die Performance nicht auf der Strecke bleibt, wäre ein Array(begrenzter Größe, also eher Cache) der/einiger freien Bereiche ratsam,
sonst müsste man im schlimmsten Fall alle Bereiche durchgehen, bis man am Ende merkt, dass überhaupt kein Speicher mehr frei ist.
Kann man das so umsetzen?
Dass ich bei meiner Methode eine hohe Fragmentierung erzeuge, weiß ich, auch dass ich pro Bereich 4 Byte zusätzlich brauche.
Wenn man die maximale Größe eines Bereiches auf 2^16 Bytes begrenzt und auch freien Speicher teilt, lässt sich das verbessern.
Alle malloc(), die ich bis jetzt gesehen habe, waren viel komplizierter, oder hat meine Methode einen großen Denkfehler, man weiß ja nie?
Edit: Ich hab noch was vergessen:
Warum funktioniert es nicht, wenn ich (wie von der Multiboot-Spez. vorgeschlagen) zur nächsten mmap wechsle, indem ich mmap->size Bytes überspringe?
Bei den ersten beiden mmap´s stimmts noch mit sizeof(struct multiboot) überein, aber danach kommen nur noch komische Werte, einer reicht ja schon, um rauszukommen.
Ich habe jetzt einmal eine eigene physische Speicherverwaltung geschrieben, die auch soweit alles macht, wie ich es will,
nur die Initialisierung funktioniertr nicht, ich hatte immer einen Nullpointer zurückbekommen, es wird phys_free(0) aufgerufen.
Diesen Fehler konnte ich nun dadurch beseitigen, dass ich
Code: [Auswählen]
if (mmap->type == 1 && mmap->base != 0)geschrieben habe, aber woran kann es liegen, dass der Bootloader von Qemu einen Bereich ab 0 als frei markiert?Wirklich frei ist er nicht, denn Qemu schmiert ab, wenn ich nach 0 etwas schreibe (Nullpointer sind auch einfach böse
)Dann habe ich noch eine Frage bezgl. Modulen:
Würde es funktionieren, wenn am Anfang eines Modules (als flache Binary wahrscheinlich) eine Funktion ist, die einen Kernel-Interrupt aufruft,
die einen Pointer auf eine Tabelle mit Kernel-Funktionen zurückgibt (darunter auch eine, die das Modul aufruft, um sich selbst zu registrieren)?
Oder kann es sein, dass ich gerade das Modulsystem von Linux beschrieben habe?
Eine Idee, wie man eine Speicher-/Heapverwaltung umsetzen könnte, habe ich auch noch:
Am Anfang ist der ganze Speicher ein Bereich, am Anfang jedes Bereiches liegt ein uint32_t (vllt. überdimensioniert),
der die Größe des Bereiches angibt und ob er frei/belegt ist.
Will man nun zuerst Speicher allozieren, so setzt man den Anfang des ersten freien Bereiches, der groß genug ist,
die Größe des belegten Platzes und dass er belegt ist, geschrieben und hinter diesen Bereich die Größe des restlichen freien Speichers.
Um einen Bereich wieder frei zu geben, markiert man diesen wieder als frei und verbindet ihn wenn möglich mit dem freien Speicher dahinter.
Damit die Performance nicht auf der Strecke bleibt, wäre ein Array(begrenzter Größe, also eher Cache) der/einiger freien Bereiche ratsam,
sonst müsste man im schlimmsten Fall alle Bereiche durchgehen, bis man am Ende merkt, dass überhaupt kein Speicher mehr frei ist.
Kann man das so umsetzen?
Dass ich bei meiner Methode eine hohe Fragmentierung erzeuge, weiß ich, auch dass ich pro Bereich 4 Byte zusätzlich brauche.
Wenn man die maximale Größe eines Bereiches auf 2^16 Bytes begrenzt und auch freien Speicher teilt, lässt sich das verbessern.
Alle malloc(), die ich bis jetzt gesehen habe, waren viel komplizierter, oder hat meine Methode einen großen Denkfehler, man weiß ja nie
?Edit: Ich hab noch was vergessen:
Warum funktioniert es nicht, wenn ich (wie von der Multiboot-Spez. vorgeschlagen) zur nächsten mmap wechsle, indem ich mmap->size Bytes überspringe?
Bei den ersten beiden mmap´s stimmts noch mit sizeof(struct multiboot) überein, aber danach kommen nur noch komische Werte, einer reicht ja schon, um rauszukommen.
