4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Bei FAT_rewind bin ich mir nicht ganz sicher, es existiert immerhin ein
    FS_ERROR FAT_fseek(file_t* file, int32_t offset, SEEK_ORIGIN whence).

    remove geht nicht, weil kein 8+3 Filename "screen__txt" übergeben wurde, sondern "screen.txt". Das wird jetzt im Filemanager erledigt, da die Funktion FormatFileName(...) seit neuestem dort ist.

    Jetzt gehts (ausprobiert mit screen.txt auf Floppy). Habe den "remove" Test in video.c belassen für eigene Versuche (auskommentiert ab Zeile 273):

    Rev. 575 (0.0.1.14)

    0
  • M

    Erhard Henkes schrieb:

    Bei FAT_rewind bin ich mir nicht ganz sicher, es existiert immerhin ein
    FS_ERROR FAT_fseek(file_t* file, int32_t offset, SEEK_ORIGIN whence).

    Ich bin mir völlig sicher.

    Denn, wie ich schon sagte, rewind(file) ist äquivalent zu fseek(file, 0, SEEK_SET), also kann man rewind so implementieren, das es den o.g. fseek-Aufruf durchführt, welcher dann u.a. FAT_fseek aufruft. Genau so hab ich es gemacht.

    0
  • E
    Mod

    @MrX: Ja, du hast völlig Recht. Siehe: http://openbook.galileocomputing.de/c_von_a_bis_z/016_c_ein_ausgabe_funktionen_014.htm#mjff798e62f1469fc3901b349f005d6547
    Gut gemacht. 👍

    0
  • E
    Mod

    Rev. 576 (0.0.1.15):
    FS_ERROR FAT_rename(const char* fileNameOld, const char* fileNameNew, partition_t* part)
    FS_ERROR FAT_fileRename (FAT_file_t* fileptr, const char* fileName)

    Getestet mit Floppy, funktioniert. 🙂

    Testcode siehe video.c, Zeile 273 ff.

    //rename test 
    waitForKeyStroke();
    uint32_t error = rename(Pfad,"1:/scrnew.txt"); 
    printf("\nrename test: error: %u", error);

    // remove test 
    waitForKeyStroke();
    error = remove(Pfad); 
    printf("\nremove test: error: %u", error);
    waitForKeyStroke();
    0
  • E
    Mod

    Rev. 577 (0.0.1.16):

    rename funktioniert nun auch mit rename(Pfad,"scrnew.txt") und mit Floppy und USB MSD.

    Test in video.c ab Zeile 273 (auskommentiert)

    getFilename angepasst, damit keine Pfadangabe vor dem Filenamen notwendig ist.

    const char* getFilename(const char* path)
{
    if (strchr((char*)path,'/')==NULL && strchr((char*)path,'|')==NULL && strchr((char*)path,'\\')==NULL)
    {
        return path;
    }
    else
    {
        // ...
    }
}
    0
  • M

    Version 0.0.1.17:

    - FormatFileName wieder in fat.c (War doch besser dort aufgehoben)
    - initrd etwas umgebaut

    0
  • M

    Version 0.0.1.18

    - fsmanager auf fgetc/fputc umgestellt
    -- Bedingt durch fehlendes caching im FAT-Treiber ists sehr langsam
    - FAT_fread/FAT_fwrite nur noch intern im FAT-Treiber genutzt
    - getch im Kernel eingebaut -> CPU-Sparen mit hlt

    0
  • E
    Mod

    Erste Tests:

    strg+s (screenshot auf floppy) und strg+u (screenshot auf usb-stick) gehen noch gleich schnell, Schreibvorgänge sind im FAT-Modul bereits gecacht. 👍

    ttt.elf laden:

    a1) Floppy real: wird jedes byte einzeln per sector lesen geladen (lese-cache notwendig), real abgebrochen zum Schutz des FDD

    a2) Floppy Qemu: geht (etwas langsamer ^^)

    b1) USB-Stick real: #PF (schreiben in read-only area ??), entweder bug eingebaut oder technik geht so nicht (MrX: bitte prüfen und kommentieren)

    b2) USB-Stick VMWare-Player: wird jedes byte einzeln per sector lesen geladen (lese-cache notwendig), interessanter Dauertest für OS und Stick (auch nett: Stick ziehen, dauer-rot auf screen ^^)

    Ein interessanter Trümmerhaufen, aus dem Phoenix aus der Asche wieder erstehen soll. 😉

    Die Grundfrage ist die, ob nach erfolgreichem Read-Cache-Einbau die Performance nicht doch leidet durch die vielen zusätzlichen Abläufe zwischen dem Lesen der Bytes mit fgetc. 😕

    0
  • E
    Mod

    0.0.1.19 (SVN Rev. 580)

    Read Cache für readSector funktioniert wie gewünscht. 🙂

    Leider existiert ein Problem beim Laden von usb-stick (Ursache noch nicht untersucht)

    0
  • E
    Mod

    0.0.1.20 (Rev. 581)

    ➡ Problem: malloc spinnt! (seit 0.0.1.18) keiner weiß warum ^^

    Es passiert, wenn ein programm einmal geladen wird (muss nicht ausgeführt werden)

    file->name von pointer auf array umgestellt, wegen Analogie zu FAT_file->name (dort exakt 8+3), hilft aber nicht beim aktuellen Problem, sollte aber ansonsten fehlersicherer sein, da man dabei nicht vergessen kann malloc(...) auszuführen.

    0
  • E
    Mod

    malloc/free beginnend vom Start verfolgt:

    void* malloc(uint32_t size, uint32_t alignment)
{
    //...

    // debug
    textColor(0x0E);    
    printf("\nmalloc: %X",address);
    textColor(0x0F);
    waitForKeyStroke();

    return address;
}

void free(void* address)
{
    // debug
    textColor(0x0E);
    printf("\nfree: %X",address);
    textColor(0x0F);
    waitForKeyStroke();

    //...
}

    Fazit: Da passt nix zusammen! 🙄

    Beweis-Foto: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_20_malloc_free_problem.PNG

    malloc    free
--------------------------------------
C0000000   
          C0000048
          00000000
C0004CC0  
          C0204CC0          
          C0000568
          C0000690
          C0000038

    usw.

    Absoluter Nonsens zur Zeit.

    0
  • M

    Version 0.0.1.21

    - malloc auf Placement umgestellt (HACK), free auskommentiert (HACK)
    -> PrettyOS funktioniert wieder, Fehler in malloc
    - Memory-Leak in executeFile behoben (durch HACK von oben wirkungslos) und unsinnigen Code dort weggemacht
    - Ehenkes Umbau von file_t::name auf statisches Array zurückgebaut

    0
  • E
    Mod

    PrettyOS funktioniert wieder

    stimmt leider nicht! 🙄

    Ich werde versuchen, die Ursachen zu finden und zu korrigieren. Bitte keine Änderungen vornehmen, bis ich das Committen wieder frei gebe. Hinweise auf den konkreten Haupt-Fehler sind natürlich gerne gesehen.

    0
  • E
    Mod

    Rev. 583: 0.0.1.22

    zwischenstand: log in malloc zum aufspüren von fehlern
    heap expansion evtl. nicht ok

    0
  • E
    Mod

    Rev. 584 (0.0.1.24)

    Zwischenstand zur Fehlersuche beim Expandieren des Heaps

    Committen wieder frei gegeben

    Fragen:

    1. Wo liegt der Fehler im MM (Heap)?
    2. Warum löst 1:\... das aus?
    0
  • E
    Mod

    Rev. 585 (0.0.1.25)

    Zwischenstand Heap-Erweiterungs-Problematik:
    Heap-Logger zur Analyse zeigt die Arbeitsweise des Heaps.

    http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_25_heap_problem.PNG <--- OK ?
    http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_25_heap_problem_PF.PNG <--- not OK

    0
  • E
    Mod

    Rev. 586 (0.0.1.26):

    HEAP_MIN_GROWTH = 0x40000;

    #define PLACEMENT_BEGIN ((uint8_t*)0x1200000) // 18 MiB (vorher 16 MiB)

    (Tobiking meint, das die Veränderung der Liste von außen erfolgen könnte, daher Tests mit 16/17/18/19 MiB als Placement-Untergrenze. Hatte hohen Einfluss.)

    bei mir unter qemu bei 1:\... oder 1:|... Division by zero mit eip 0x104504 (kernel.map: 0x00105499 _FAT_fread)

    Die Fehlersuche ist bisher über das Eingrenzen der Symptome nicht hinaus gewachsen.

    0
  • E
    Mod

    Rev. 587 (0.0.1.27)

    Heap-Problem erstmal gelöst: Regions Liste für Heap von 0xA00000 bis 0xE00000 gelegt. Da "unten" scheint es sicherer zu sein als zwischen 16 MiB und 20 MiB.
    Tobiking hat da auch schon negative Erfahrungen bei VBox gemacht, er sprach von tasking_install.

    jetzt geht real und auf qemu auch wieder 3:/ttt usw.

    #define _MALLOC_FREE_ sorgt für infos über malloc/free und zeigt den neuen Heap-Logger, der die "Regions", die Bausteine des Heaps, aufführt.

    Wer das MM-Problem weiter bearbeiten will:
    kheap.c:

    static const uint32_t HEAP_MIN_GROWTH = 0x40000;

    kheap.h:

    // Placement allocation
#define PLACEMENT_BEGIN   ((uint8_t*) 0xA00000)     // 10 MiB // TEST vorher 16 MiB
#define PLACEMENT_END     ((uint8_t*) 0xE00000)     // 14 MiB // TEST vorher 20 MiB

    Vorschlag aus IRC #lost von bluecode: magic einbauen und bei jedem malloc/free überprüfen, dann würden wir heap corruption zeitnah feststellen.

    placement: A00000h
    regions: B2A000h

    Da liegt Folgendes vor dem Heap:

    kernel_pd = malloc(sizeof(page_directory_t), PAGESIZE);

kernel_pd->tables[i] = malloc(sizeof(page_table_t), PAGESIZE);

// Setup the page tables for the kernel heap (3GB-4GB), unmapped
page_table_t* heap_pts = malloc(256*sizeof(page_table_t), PAGESIZE);

bittable = malloc(128*1024, 0);

    In paging.c wurde auch folgendes geändert in phys_init():

    // Check that 10 MiB-20 MiB is free for use
    if (!memorymap_availability(entries, 10*1024*1024, 20*1024*1024))
    {
        textColor(0x0C);
        printf("The memory between 10 MiB and 20 MiB is not free for use. OS halted!\n");
        for (;;);
    }

    Also bleiben für die regions-Verwaltung des Heap momentan:
    E00000h - B2A000h = 2D6000h = 2973696 Byte

    typedef struct
{
    uint32_t size;
    bool     reserved;    
} region_t;

    Größe: 4+1 Byte = 5 Byte

    Anzahl regions: 2973696 Byte / 5 Byte = 594739

    Heap-Area FF000000h - C0000000h = 1056964608 Byte

    1056964608 Byte / 594739 regions = 1777 Byte/region (passt, wackelt und hat Luft 👍 )

    0
  • C

    Rev. 588:

    * Keysound.elf als Userprogramm hinzugefügt, macht immer Beep wenn man eine Taste drückt (A-Z)

    0
  • E
    Mod

    0.0.1.28 - Rev: 589

    - stack im BL 2 nach 0x99999 (korrekt: 0x9FFFF, s.u.), da kernel jetzt bei 0x100000
    - kheap, paging (alles auf 10 MiB bis 20 MiB umgebaut)

    VBox und VMWare beklagen sich bei eingeschaltetem _MALLOC_FREE_, laufen aber ohne gut.
    Real PC und qemu laufen mit und ohne.

    0
Anmelden zum Antworten