Autor Thema: Speicher für die Bitmap suchen  (Gelesen 5776 mal)

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« am: 22. February 2009, 00:52 »
Nabend zusammen,

ich war gerade dabei mir meine Bitmap-Algorthmen anzuschauen.
Wollte ein wenig optimieren und habe mir mal den LOST-Code angeschaut.
Da habe ich mich gefragt, warum der Code funktioniert.

static struct mem_block get_free_block
    (struct multiboot_info* multiboot_info, size_t i)
{
    struct mem_block result;

    // Überprüfung der BIOS-Memory-Map
    struct multiboot_mmap* mmap;
    uintptr_t mmap_addr = multiboot_info->mi_mmap_addr;
    uintptr_t mmap_end = mmap_addr + multiboot_info->mi_mmap_length;

    for(mmap = (struct multiboot_mmap*) (mmap_addr);
        mmap < (struct multiboot_mmap*) (mmap_end);
        mmap++)
    {
        // Typ 1 steht für freien Speicher
        if (mmap->mm_type == 1) {
            if (i-- == 0) {
                result.start    = (paddr_t)((uintptr_t) mmap->mm_base_addr);
                result.end      = (paddr_t)((uintptr_t) mmap->mm_base_addr
                                + (dword) mmap->mm_length - 1);
                return result;
            }
        }
    }

    result.start = (paddr_t) 0xFFFFFFFF;
    result.end   = (paddr_t) 0;

    return result;
}

i ist bei euch ja die größe der bitmap in bytes.
Wenn ich mir das mal so anschaue sucht ihr euch den letzten freien Block, der in der GRUB-mmap liegt.
Wie kann das funktionieren?
Warum sucht ihr euch nicht einfach einen Block, der die Größe bietet, die ihr sucht.
Dann könnt ihr davon doch einfach eure größe abziehen und schon passt es.

Oder verstehe ich euren Code falsch?

[EDIT]
Ich habe mir mal aus Spaß diese Methode bei mir eingebaut und dann meldet er mir beim booten, dass er nicht genug speicher findet.
Was mich acuh nicht weiter wundert.
i = 4094 bei mir und und er findet genau zwei freie Blöcke.
Die haben jeweils mehr als genug freien Speicher.
Das verwundert mich jetzt nur umso mehr, dass der Code funktioniert
« Letzte Änderung: 22. February 2009, 01:02 von rizor »
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 22. February 2009, 08:32 »
i ist bei euch ja die größe der bitmap in bytes.
Wenn ich mir das mal so anschaue sucht ihr euch den letzten freien Block, der in der GRUB-mmap liegt.
...
Oder verstehe ich euren Code falsch?

Ich gehöre zwar nicht zum lost-Team, aber für mich sieht es danach aus, als gäbe die funktion einfach den I-ten(bei 0 angefangen zu zählen) freien block aus der grub-mmap zurück. 'I' hat also nichts mit einer Bitmap-Größe zu tun.
„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 22. February 2009, 10:15 »
Das denke ich auch. Diese Funktion und andere ähnliche in der Datei sollen wohl nur eine Art einheitlichen Iterator über Speicherbereiche bieten.
Dieser Text wird unter jedem Beitrag angezeigt.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 22. February 2009, 11:09 »
Ah verdammt.
Stimmt habe mich verlesen.
Ich dachte, dass sie die Größe der Bitmap übergeben.
Dabei übergeben sie einen counter....

Lesen sollte man können.
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 22. February 2009, 12:33 »
Wer würde denn schon eine Größe i nennen? ;)

Die Kommentierung in diesen Funktionen ist aber auch irgendwie dürftig. Mal sehen, ob ich da was nachbessern kann.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 22. February 2009, 16:28 »
Naja, Sachen anhand der Namensgebung zu bewerten habe ich mir abgwöhnt, nachdem die Professoren alles mit i,k,c,n etc betiteln.
Frei nach dem Motto Variablen mit mehr als 3 Zeichen sind schlecht und machen den Code zu verständlich. ;)
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

 

Einloggen