Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
61
OS-Design / Re: Speicherideen
« am: 01. February 2013, 15:34 »
Reaktionen sind jetzt ausdrücklich erwünscht 
16. June 2024, 04:01
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
62
OS-Design / Speicherideen
« am: 01. February 2013, 14:40 »
Ich sammele in diesem Post einige Ideen zur Verwaltung von Speicher.
Ich gehe hier von einer Speicherverwaltung mit Bitmap aus, die ich für performant(und vorallem dingen fehlersicher genug halte !!!)
1. Dynamische Arrays/Puffer im Kernel:
Es ist in Betriebsystemen häufig der Fall das man eine Liste aus Daten(strukturen) erstellen muss(zb. eine Liste aus Thread, Prozess oder User structs).
Wenn diese mehr als 4kb speicher einnehmen könnte man mit krealloc den folgenden Speicherblock alloziieren, was ist wenn der aber schon belegt ist, dann müsste man mit kmalloc(neuesize) einen neuen Bereich alloziieren und die Daten dort hinkopieren. Dann müsste man aber auch alle Pointer auf den Array ändern,was bei vergessen schnell zu fehlern führen kann.
Ich habe hier ein mehrstufiges System im Sinn:
Zunächst wird ein Block für einen Pointer alloziiert. Dieser zeigt auf eine Dynamische liste aus Puffer structs diese bestehen aus:
1. einer ID mit der man den Buffer identifizieren kann
2. einem Pointer
3. der Größe
Soll ein Buffer vergrössert werden und krealloc geht nicht, alloziert man wie besagt einen neuen Speicherbereich und kopiert die Daten dorthin; man braucht aber nur den Ptr in dem Puffer struct zu ändern weil nur dieser als Pointer benutzt werden sollte. Wird die dynamische Liste aus Puffer structs größer als 4k ändert man den zuerst erwähnten Pointer.
Der Vorteil daran ist ,dass man z.b nicht für jeden einzelnen task 4kb alloziieren muss wie im Beispielkernel und dass man über einen Offset oder Index direkt auf einen einzelnes Element zugreifen kann. Außerdem verhindert dass Verfahren recht effektiv Bufferoverflows.
2. Kopieren/bewegen großer Datenmengen auf der RAM über DMA und externe Datenträger
Meine memmove und memcpy funktionen kopieren den Speicher ganz konventionel mit XCHG und einer Schleife.
Das ist sehr langsam(1 ganze sekunde[!] fur 4kb).
Natürlich könnte ich das mit AVX achtmal schneller machen, aber das allein ist mir zu spießig
Man könnte wenn ein beschreibbarer externer Datenträger verfügbar ist, den SATA Host Controller oder USB Hub dazu nutzen den zu bewegenden Speicherbereich erst in eine Datei in dem Datenträger und dann zurück in das zielgebiet zu kopieren.
Der clue daran:
Die CPU(s) selbst werden kein bisschen zusätzlich belastet Der Host controller,der auf das kopieren großer Datenmengen ausgelegt ist macht alles selber über DMA.
Problem:
Wenn man auf der CPU einfach fortfährt könnte es zu RaceConditions kommen weil die CPU beispielsweise bereits auf die kopierten Speicherbereich zugreifen will, bevor alles kopiert ist.
Damit man nicht doch auf der CPU warten muss bis alles fertig ist würde ich einfach den Registersatz des Kernels speichern und den Thread wegschedulen. Ich würde ihn dann so lange weggeschedult lassen bis alles fertig ist und DANN(wenn alles kopiert ist) den Registersatz wieder herstellen.
Mit memset wäre das dann ganz ähnlich.
Ich habe DMA, PCI,USB und SATA alles noch nicht implementiert, wüsste also gern was ich verändern muss, Ich finde einfach die Idee cool die Speichercontroller so umzufunktionieren.
Es wäre gut zu wissen wie und ob meine Ideen in Linux, FreeBSD oder tyndur umgesetzt sind und ob man noch was verbessern kann
Ich gehe hier von einer Speicherverwaltung mit Bitmap aus, die ich für performant(und vorallem dingen fehlersicher genug halte !!!)
1. Dynamische Arrays/Puffer im Kernel:
Es ist in Betriebsystemen häufig der Fall das man eine Liste aus Daten(strukturen) erstellen muss(zb. eine Liste aus Thread, Prozess oder User structs).
Wenn diese mehr als 4kb speicher einnehmen könnte man mit krealloc den folgenden Speicherblock alloziieren, was ist wenn der aber schon belegt ist, dann müsste man mit kmalloc(neuesize) einen neuen Bereich alloziieren und die Daten dort hinkopieren. Dann müsste man aber auch alle Pointer auf den Array ändern,was bei vergessen schnell zu fehlern führen kann.
Ich habe hier ein mehrstufiges System im Sinn:
Zunächst wird ein Block für einen Pointer alloziiert. Dieser zeigt auf eine Dynamische liste aus Puffer structs diese bestehen aus:
1. einer ID mit der man den Buffer identifizieren kann
2. einem Pointer
3. der Größe
Soll ein Buffer vergrössert werden und krealloc geht nicht, alloziert man wie besagt einen neuen Speicherbereich und kopiert die Daten dorthin; man braucht aber nur den Ptr in dem Puffer struct zu ändern weil nur dieser als Pointer benutzt werden sollte. Wird die dynamische Liste aus Puffer structs größer als 4k ändert man den zuerst erwähnten Pointer.
Der Vorteil daran ist ,dass man z.b nicht für jeden einzelnen task 4kb alloziieren muss wie im Beispielkernel und dass man über einen Offset oder Index direkt auf einen einzelnes Element zugreifen kann. Außerdem verhindert dass Verfahren recht effektiv Bufferoverflows.
2. Kopieren/bewegen großer Datenmengen auf der RAM über DMA und externe Datenträger
Meine memmove und memcpy funktionen kopieren den Speicher ganz konventionel mit XCHG und einer Schleife.
Das ist sehr langsam(1 ganze sekunde[!] fur 4kb).
Natürlich könnte ich das mit AVX achtmal schneller machen, aber das allein ist mir zu spießig
Man könnte wenn ein beschreibbarer externer Datenträger verfügbar ist, den SATA Host Controller oder USB Hub dazu nutzen den zu bewegenden Speicherbereich erst in eine Datei in dem Datenträger und dann zurück in das zielgebiet zu kopieren.
Der clue daran:
Die CPU(s) selbst werden kein bisschen zusätzlich belastet Der Host controller,der auf das kopieren großer Datenmengen ausgelegt ist macht alles selber über DMA.
Problem:
Wenn man auf der CPU einfach fortfährt könnte es zu RaceConditions kommen weil die CPU beispielsweise bereits auf die kopierten Speicherbereich zugreifen will, bevor alles kopiert ist.
Damit man nicht doch auf der CPU warten muss bis alles fertig ist würde ich einfach den Registersatz des Kernels speichern und den Thread wegschedulen. Ich würde ihn dann so lange weggeschedult lassen bis alles fertig ist und DANN(wenn alles kopiert ist) den Registersatz wieder herstellen.
Mit memset wäre das dann ganz ähnlich.
Ich habe DMA, PCI,USB und SATA alles noch nicht implementiert, wüsste also gern was ich verändern muss, Ich finde einfach die Idee cool die Speichercontroller so umzufunktionieren.
Es wäre gut zu wissen wie und ob meine Ideen in Linux, FreeBSD oder tyndur umgesetzt sind und ob man noch was verbessern kann
63
Lowlevel-Coding / .asm vs .S
« am: 01. February 2013, 13:46 »
Ich wollte einfach mal nachfragen ob der Linker oder Assembler irgendwas "anders macht" wenn man seine assembler Dateien auf .asm statt .S enden lässt.
64
Lowlevel-Coding / Re: Physische Speicherverwaltung- Bitmaps
« am: 27. January 2013, 19:53 »Okay, danke schon mal. Wenn ich überprüfe, welche Blöcke frei sind, sind das doch auch 4kB Blöcke, oder? Bietet es sich dann nicht so, eine Speicherseite auch 4kB groß zu machen, oder was spricht dagegen?Belegte Brotchen sind gleichgroß wie nichtbelegte
In der Bitmap ist aber steht natürlich nur ein Bit für einen Block.
65
Lowlevel-Coding / Re: Physische Speicherverwaltung- Bitmaps
« am: 27. January 2013, 19:47 »
sry ich meinte mit Block und Speicherseite das selbe. Die Speicherseiten fürs PAGING müssen 4kb 4mb oder 2mb groß sein, steht jedenfalls im Wiki.
66
Lowlevel-Coding / Re: Physische Speicherverwaltung- Bitmaps
« am: 27. January 2013, 19:18 »
Ich verstehe Speicherverwaltung schon(habs auch schon umgesetzt) aber ich weiß nicht ganz wie ich das testen kann. Wenn was nich funzt dann merk ich das ja nicht sofort sondern ich wundere mich bloß wenn meinKernel größer ist, dass er ständig abstürzt wegen den RaceConditions die so entstehen können.
67
Lowlevel-Coding / Re: Physische Speicherverwaltung- Bitmaps
« am: 27. January 2013, 19:14 »
Ein zu verwaltender Block oder eine zu verwaltende Speicherseite kann so groß, klein sein wie du willt 4kb ist aber gerade günstig wegen Paging blablabla
PATCH weil der Begriff "Speicherseite" beim Paging verwendet wird
-Ein zu verwaltender Block oder eine zu verwaltende Speicherseite kann so groß, klein sein wie du willt 4kb ist aber gerade günstig wegen Paging blablabla
+Ein zu verwaltender Block kann so groß, klein sein wie du willt 4kb ist aber gerade günstig wegen Paging blablabla
PATCH weil der Begriff "Speicherseite" beim Paging verwendet wird
-Ein zu verwaltender Block oder eine zu verwaltende Speicherseite kann so groß, klein sein wie du willt 4kb ist aber gerade günstig wegen Paging blablabla
+Ein zu verwaltender Block kann so groß, klein sein wie du willt 4kb ist aber gerade günstig wegen Paging blablabla
68
Lowlevel-Coding / Re: Physische Speicherverwaltung- Bitmaps
« am: 27. January 2013, 19:09 »
Also jetzt mal ganz von vorne: Das Bitmap ist ein Puffer indem jedes bit für einen Speicherblock steht und zwei Werte haben kann(z.b 0 für Blockfrei und 1 für Blockbelegt)Was verstehst du jez nich? die Anzahl der zu verwaltenden Blöcke ist sizeof(Bitmap)*8
69
Offtopic / Re: UEFI Dualboot Windows + Linux
« am: 27. January 2013, 18:31 »Swapping ist zwar sehr langsam, aber ich werde es wahrscheinlich trotzdem in meinem OS umsetzen weils ein cooles Feauture ist und aus Nostalgie (ohne Swapping würde heute niemand von Linux reden)Das ist keine zum Thema wirklich beitragende Antwort, aber ich habe hier auch ein Z77-MB mit 16 GB RAM (was auch immer der zur Sache tut)Falls sich jemand fragt, wozu ich 20GB Swap habe!
71
Lowlevel-Coding / Re: outb
« am: 23. January 2013, 22:02 »
Achso Ich habe aber auch gesehen dass memset im BeispielKernel als inline deklariert wurde bei so einer größeren funktion die auch aus mehreren hundert src files aufgerufen wird ist das vllt nicht so sinnvoll.
72
Lowlevel-Coding / Re: outb
« am: 23. January 2013, 18:36 »
Inline Deklaration ist das nicht auch iwie performanter in der Ausführung aber erzeugt mehr Opcode ähnlich wie bei Makros??
73
Lowlevel-Coding / Re: Interrupts funktionieren nicht
« am: 23. January 2013, 18:34 »
Der Vram Puffer in der RAM wird dann von iwelchen Daten Überschrieben die da nich hingehören.
74
Lowlevel-Coding / Re: outb
« am: 22. January 2013, 20:01 »
Du kannst das auch vom beispielkernel_repo src code "inspirieren lassen"(http://git.tyndur.org/?p=tutorial.git;a=summary)
stdint.h:
stdint.h:
Code: [Auswählen]
#ifndef STDINT_H
#define STDINT_H
typedef unsigned long long uint64_t;
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
typedef signed long long int64_t;
typedef signed int int32_t;
typedef signed short int16_t;
typedef signed char int8_t;
// size
typedef unsigned int size_t;
// Signed pointer-sized integer
typedef long intptr_t;
// Unsigned pointer-sized integer
typedef unsigned long uintptr_t;
#endif
75
Lowlevel-Coding / Re: outb
« am: 22. January 2013, 19:55 »
So schaut das bei mir aus damit kannst du die IOPorts von deinem Prozessor ansteuern. Das inline ASM werde ich aber wahrscheinlich in der HAL "makrotisieren"
Cursor verschieben geht bei mir aber auch so nicht
.
Cursor verschieben geht bei mir aber auch so nicht
.Code: [Auswählen]
#include<stdint.h>
#include<drv/io/ioport.h>
/* writes a byte into an I/O-Port */
void outb(uint16_t port, uint8_t data)
{
asm volatile ("outb %0, %1" : : "a" (data), "Nd" (port));
}
/* reads a Byte from an I/O-Port */
uint8_t inb(uint16_t port){
uint8_t result;
asm ("inb %1, %0" : "=a" (result) : "Nd" (port));
return result;
}
77
Lowlevel-Coding / Re: Qemu
« am: 22. January 2013, 17:43 »
Ja schön aber früher oder später brauchst du trotzdem die .iso wenn du dein OS auf echter HW laufen lassen willst.
hast du mkisofs und stage2_eltorito, sodass du die .iso so erstellen kannst?
hast du mkisofs und stage2_eltorito, sodass du die .iso so erstellen kannst?
Code: [Auswählen]
mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o cdrom.iso cdrom_files/
78
Lowlevel-Coding / Re: Qemu
« am: 22. January 2013, 17:20 »
[quote von Wiki]
Unter Windows gibt es noch keine Möglichkeit, ein CD-Image von GRUB2 zu erstellen.[/quote]
Also versuchs mal mit GRUB 1
Unter Windows gibt es noch keine Möglichkeit, ein CD-Image von GRUB2 zu erstellen.[/quote]
Also versuchs mal mit GRUB 1
79
Lowlevel-Coding / Re: Qemu
« am: 22. January 2013, 16:15 »@Martin Erhardt: Ich weiß ehrlich gesagt nicht so ganz was ich da machen soll, wenn ich einfach nur die Kernel-Datei auf ein image tu, klappt das doch sicher nicht, oder?doch also es gibt ja den Multiboot standard nach dem der Multiboot Header in den ersten 8KB sein muss, gefolgt vom kernel.
Code: [Auswählen]
.section .text
// Init ist eine Funktion aus init.c
.extern init
#define MB_MAGIC 0x1badb002
#define MB_FLAGS 0x0
#define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)
// Der Multiboot-Header
.align 4
.int MB_MAGIC
.int MB_FLAGS
.int MB_CHECKSUM
// _start muss global sein, damit der Linker es findet und als Einsprungspunkt
// benutzen kann (alle Labels, die nicht global sind, sind nur in dieser Datei
// sichtbar)
.global _start
_start:
// Stack initialisieren
mov $kernel_stack, %esp
// C-Code aufrufen
call init
// Falls wir jemals aus init zurueckkommen sollten, sperren wir die Interrupts und
// halten einfach den Prozessor an. (man braucht ihn ja nicht unnötig heißlaufen lassen.)
_stop:
cli
hlt
// Sollte es doch weitergehen, probieren wir erneut die CPU schlafen zu lassen
jmp _stop
// 8 kB Stack fuer den Kernel. Das Label steht hinter dem freien Speicher,
// weil der Stack nach unten waechst
.section .bss
.space 8192
kernel_stack:Wenn Start.S so ungefähr aussieht dann geht dass
80
Lowlevel-Coding / Re: Qemu
« am: 22. January 2013, 15:59 »
Ja, gibt's auch Tools : http://wiki.osdev.org/Bootable_El-Torito_CD_with_GRUB_Legacy, http://wiki.osdev.org/Disk_Images, http://wiki.osdev.org/Windows_Tools
Ich habe leider bloß die englischen Artikel gefunden auf die schnelle.
Ich habe leider bloß die englischen Artikel gefunden auf die schnelle.