Sourcecode Fortschritt
-
0.0.1.200 - Rev: 779
Kernel: 515.560 Byteshttp://www.pcidatabase.com/pci_c_header.php (nach Überarbeitung durch Erhard Henkes wegen massiver bugs in der Produkt-Liste, ca. 1h Aufwand) eingebaut zur Erkennung von Devices.
Noch nicht an pci-scan angeschlossen. Bitte erst testen.
bei mir: qemu und PC laufen noch.
-
Diese Liste kostet ca. 300 KB. Ich weiß ja nicht, ob wir uns wirklich 20 % der Floppy damit vollstopfen wollen...
-
0.0.1.201 - Rev: 780
pciVendProdList.h verwendet zur Auswertung in pciScan(...)
Beispiel qemu:
#0 0:0.0 IRQ:0 Intel PCI & Memory #1 0:1.0 IRQ:0 Intel PIIX3 PCI-to-ISA Bridge (Triton II) #2 0:1.1 IRQ:0 Intel PIIX3 IDE Interface (Triton II) #3 0:1.2 IRQ:11 Intel USB EHCI Controller USB EHCI F0000000h MMIO sz:4096 #4 0:1.3 IRQ:9 Intel PIIX4/4E/4M Power Management Controller #5 0:2.0 IRQ:0 Cirrus 64-bit VisualMedia Accelerator #6 0:26.0 IRQ:10 Realtek Realtek RTL8139 Family PCI Fast Ethernet NIC
-
Diese Liste kostet ca. 300 KB. Ich weiß ja nicht, ob wir uns wirklich 20 % der Floppy damit vollstopfen wollen...
@MrX: man kann es ja weg lassen mittels #define _PCI_VEND_PROD_LIST_
-
0.0.1.202 - Rev: 781
nur IRQ != 255 angezeigt
Aktuelle Liste von VBox:
#1 0:1.0 IRQ:0 Intel PIIX3 PCI-to-ISA Bridge (Triton II) #2 0:1.1 IRQ:0 Intel PIIX4/4E/4M IDE Controller #3 0:2.0 IRQ:11 vend:80EEh dev:BEEFh #4 0:3.0 IRQ:10 Intel Gigabit Ethernet Controller #5 0:4.0 IRQ:9 vend:80EEh dev:CAFEh #6 0:5.0 IRQ:5 Intel Aureal (AD1881 SOUNDMAX) Placa Mãe Asaki P3-141 #7 0:6.0 IRQ:11 vend:106Bh dev:003Fh USB OHCI F0804000h MMIO sz:4096 #8 0:7.0 IRQ:9 Intel PIIX4/4E/4M Power Management Controller #9 0:8.0 IRQ:9 AMD PCnet LANCE PCI Ethernet Controller #10 0:11.0 IRQ:10 Intel USB 2.0 EHCI Controller USB EHCI F0900000h MMIO sz :4096
das klingt komisch:
vend:80EEh dev:BEEFh <---- BEEF (vendor 80EEh gibt es nicht)
vend:80EEh dev:CAFEh <---- CAFEvend:106Bh dev:003Fh <--- der Hersteller soll Apple sein, aber Device 003Fh gibt es nicht
-
0.0.1.203 - Rev: 782
memory.h eingefügt
Paging.h/c formal überarbeitet
-
0.0.1.203 - Rev: 783
memory.h nachgereicht
-
0.0.1.204 - Rev: 784
ESC + p zeigt die Belegung der physischen Bittabelle (paging.c). Jedes Bit dort repräsentiert eine physische Page (auch Frame genannt):
0 = frei (grün),
1 = bereits belegt (grau)Man sieht, dass PrettyOS 23 1/4 MiB für sich verwendet.
Test mit VBox und 24 MiB RAM eingestellt: Laden von mehreren User-Programmen (ca. 10) führt zum #PF mit error 6 (bit1: write access und bit2: user mode access)
http://www.c-plusplus.net/forum/viewtopic-var-t-is-264710.htmlMit obigem physicalMem-Logger kann man diesen Vorgang illustrativ verfolgen.
-
version 0.0.1.204 - Rev: 785
vbe.c/h
- Kommentare entfernt, geändert u. hinzugefügtother_userprogs/vgatest.c entfernt
-
version 0.0.1.204 - Rev: 786
audio/sb16.c/.h
- Informationen für die Programmierung eines Audiotreibers zusammengelegt (Soundblaster16).
-
Version 0.0.1.205:
- event_list in todo_list umbenannt. Verbessert/Verallgemeinert. Nutzung reduziert.
- memory.txt ergänzt
- Includes aufgeräumt
- Bootablauf verändert, Ausdruck verbessert.
- Sonstiges^^
-
0.0.1.206 - Rev: 788
PCI_VEND_PROD_LIST_H weiter überarbeitet (teilweise echt übel, benötigt leider noch viel Arbeit)
-
0.0.1.207 - Rev: 789
PCI_VEND_PROD_LIST_H weiter überarbeitet
Wenn wir da alle mithelfen, kann diese Liste wertvoll werden.
In der Urform ist sie nicht zu gebrauchen gewesen.
-
0.0.1.208 - Rev: 790
Freigabe des Userstacks:
// free memory for user stack if (task->userStack != 0) { paging_free (task->page_directory, task->userStack, task->userStackSize * PAGESIZE); }
Test mit VBox und 24 MiB RAM:
Zweimal ttt starten, dann das zweite ttt beenden, anschließend das erste.
Man erkennt, dass zwei Pages noch nicht frei gegeben werden beim "kill".
-
0.0.1.209 - Rev: 791
nach user-stack paging_free nun auch: user-PD und user-PT auf dem heap wird wieder freigegeben
zwei pages auf dem physischen speicher sind allerdings noch belegt nach user-task kill// free memory for user stack if (task->userStack != 0) { paging_free (task->page_directory, task->userStack, task->userStackSize * PAGESIZE); if (task->page_directory != kernel_pd) { free(task->page_directory); free(task->userPT); } }
So sieht das aus, wenn man 4 mal ttt startet und beendet:
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_209_physMem.PNGMan sieht, dass dieser Speicher vor dem user-stack (10 Pages) belegt wird. Die 10 Pages vom user-stack werden also sauber wieder frei gegeben.
Auf dem Heap fällt "ring-element" auf.
MrX im IRC:
hätte ring_DeleteFirst ein Memory Leak, müsste der Heap eigentlich platzen. Dann würde bei jedem Tastedruck Speicher verplempert.
-
0.0.1.210 - Rev: 792
Speicher-Leck ( http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_209_physMem.PNG ) abgedichtet! In elf.c allokierter speicher für das user-programm wird nun auch frei gegeben. Damit ist der Speicher nach Beenden des Programms wieder wie vorher. Typisch sind momentan 2 Frames für das User-Programm (elf.c) und 10 Frames für den User-Stack (task.c).
task.c, void kill(task_t* task):
paging_free (task->page_directory, task->userStackAddr, task->userStackSize * PAGESIZE); paging_free (task->page_directory, task->userProgAddr, task->userProgSize); if (task->page_directory != kernel_pd) { free(task->page_directory); free(task->userPT); }
-
0.0.1.211 - Rev: 793
kleine Korrekturen
-
Version 0.0.1.212:
- Diverse Bugfixe:
-- Compiliert nun auch mit NASM 2.09 (Optimerungsschalter mussten für VBE und BL1 auf O1 oder O0 stehen)
-- Makefile kompiliert auch audio-Verzeichnis, in dem auch sys_speaker.h/c liegen
-- Scheduler: Bug beim killen von schlafenden tasks behoben
- kernelTask und kernelConsole sind nun nicht mehr dynamisch allokiert, da sie immer da sein sollen
- operatoren new, new[], delete und delete[] in C++-Userlib ergänzt
- Aufgeräumt
-
0.0.1.213 - Rev: 795
va_end(ap); eingebaut
#define _MEMLEAK_FIND_ macht Probleme bei VBox und VMWare, indirekt auch beim PC, also nur auf qemu einsetzen.
Problem muss bei writeInfo(...) liegen, denn auskommentiert läuft VBox.
-
0.0.1.214 - Rev: 796
#define _MEMLEAK_FIND_
Problem, das zum Absturz bei VMWare und VBox führt, gefunden:
#ifndef OS_H #define OS_H #include "types.h" // These switches change the behavior of PrettyOS, useful for analyzing tasks: /// #define _DIAGNOSIS_ // Diagnosis-Output - activates prints to the screen about some details and memory use /// #define _MALLOC_FREE_ // shows information about malloc/free and heap expansion #define _MEMLEAK_FIND_ // Provides a counter of all (successful) malloc and free calls showing memory leaks /// #define _USB_DIAGNOSIS_ // only as transition state during implementation of USB 2.0 transfers /// #define _FAT_DIAGNOSIS_ // only as transition state during implementation of FAT 12/16/32 /// #define _DEVMGR_DIAGNOSIS_ // e.g. sectorRead, sectorWrite /// #define _TASKING_DIAGNOSIS_ // Provides output about tasking and scheduler /// #define _FLOPPY_DIAGNOSIS_ // Provides information about the floppy(-motor) /// #define _VM_DIAGNOSIS_ // Provides information about the vm86 task, but critical /// #define _SOUND_ // This is no sound, only "beep". Better stop it! ^^ #define _PCI_VEND_PROD_LIST_ // http://www.pcidatabase.com/pci_c_header.php
void writeInfo(uint8_t line, char* args, ...) { va_list ap; va_start(ap, args); vsnprintf(infoBar[line], 81, args, ap); va_end(ap); // refreshUserScreen(); // HACK <--- leads to massive error in VBox and VMWare }
Nun ist der schwarze Peter bei refreshUserScreen()
void refreshUserScreen() { // Printing titlebar kprintf("PrettyOS [Version %s] ", 0, 0x0C, version); if (displayedConsole == KERNELCONSOLE_ID) { cursor.x = COLUMNS - 5; kputs("Shell"); } else { char Buffer[70]; snprintf(Buffer, 70, "Console %u: %s", displayedConsole, reachableConsoles[displayedConsole]->name); cursor.x = COLUMNS - strlen(Buffer); cursor.y = 0; kputs(Buffer); } kprintf("--------------------------------------------------------------------------------", 1, 7); // Separation if(reachableConsoles[displayedConsole]->showInfobar) { // copying content of visible console to the video-ram memcpy(vidmem + USER_BEGIN * COLUMNS, reachableConsoles[displayedConsole]->vidmem, COLUMNS * (USER_LINES-4) * 2); memsetw(vidmem + (USER_BEGIN + USER_LINES - 3) * COLUMNS, 0, 3 * COLUMNS); // Clearing info-area kprintf("--------------------------------------------------------------------------------", 44, 7); // Separation kprintf(infoBar[0], 45, 14); kprintf(infoBar[1], 46, 14); kprintf(infoBar[2], 47, 14); } else { // copying content of visible console to the video-ram memcpy(vidmem + USER_BEGIN * COLUMNS, reachableConsoles[displayedConsole]->vidmem, COLUMNS * USER_LINES*2); } kprintf("--------------------------------------------------------------------------------", 48, 7); // Separation cursor.y = reachableConsoles[displayedConsole]->cursor.y; cursor.x = reachableConsoles[displayedConsole]->cursor.x; update_cursor(); }