Thema: Mikrokernel - Frage

[FreakyPenguin]

Hallo

Ich bin dabei einen Mikrokernel zu entwickeln. Nun habe ich dazu noch ein paar Punkte die mir noch nicht klar geworden sind.

Im moment beschäftige ich mich vorallem mit der Speicherverwaltung. Ich möchte versuchen, die Speicherverwaltung ganz aus dem Kernel zu verbannen. Aber beim initialisieren des Systems muss ich wohl eine temporäre Speicherverwaltung einrichten, oder? Wie verwalte ich denn dort den Speicher am einfachsten? Bis jetzt habe ich das ganze im Kernel mit einer Linked-List gelöst, was aber nicht sehr praktisch ist, um dem Pager mitzuteilen, über welche Bereich er verfügen darf. Welcher Ansatz ist denn hier am sinnvollsten?

Vielen Dank

MfG Toni

[T0ast3r]

mach doch einfach deine Speicherverwaltung als eigenes vom Kernel mehr oder wenige unabhängiges Modul, welches du dann beim booten lädst und dir Funktionen bereit stellt

Es ist am besten den physikalischen Speicher als Heap zu verwalten, das ist i.a. schnell und effektiv.
Dabei solltest du dir die Grundsätze von Heaps anschauen.
Z.b. könntest du (wie in homixOS) alle vorhandenen Pages auf einen Page-Stack pushen, wird eine benötigt wird eins gepoppt und wird eins freigegeben wirds gepusht; dies wäre die schnellste (aber undynamische) Lösung
du könntest den Speicher auch mit einem Heap Tree beschreiben wo jeder node zwei childs hat
nicht zu empfehlen sind bitmaps, bei denen du den Status jeder einzlenen Page speicherst

lg,

Toaster

[nooooooooos]

Wiso was ist an Bitmaps schlecht??

[bluecode]

Die sind sehr langsam beim allozieren einer Page (O(N), d.h. die benötigte Zeit steigt linear mit der Anzahl der Pages), sind dafür aber beim allozieren von mehreren zusammenhängenden Pages sinnvoll. Bei einem Stack ist allozieren und free O(1), d.h. die benötigte Zeit ist unabhängig von der Anzahl der Pages bzw. konstant.

aber was in dem Zusammenhang (un)dynamisch sein soll, ist/war mir ein Rätsel

edit: Der speicherverbraucht ist bei bitmaps aber auch geringer als bei einem Stack. Sollte man auch beachten... insofern hat alles seine Vor- & Nachteile.
edit2: Wobei man mit einem Trick den Speicherverbraucht eines Stacks auch unter den einer Bitmap senken kann...

[nooooooooos]

Aber wie sehen die Vor + Nachteile eines Baumes aus??

[MNemo]

Keine Ahnung wie das mit einem Baum gehen soll

,aber ein weiteterer vorteil von Bitmaps ist, das man z.B.feste physiche addressen leichter mappen kann
(0xB8000 für den grafik spicher oder den Speicher für PCI, APIC)
mit einem Stack geht das nicht (oder ?)

( ich hoffe ihr versteht was ich meine )

[bluecode]

( ich hoffe ihr versteht was ich meine )

Meinst du, dass du dein Stack nach der Adresse durchsuchen musst und dann die Adresse daraus entfernen? Ich würd solche Speicherbereich von vorneherein nicht in dem Stack speichern, sondern nur den Speicher, der wirklich frei verwendet werden kann.

[T0ast3r]

@bluecode, die allokierbare größe ist undynamisch bei bitmaps/stack

Aber wie sehen die Vor + Nachteile eines Baumes aus??

Man kann beliebige 2^n Speichereinheiten verwalten, da jeder node zwei child hat.
Bei ToasterOS kann man so startend ab 32 B, 64 B, 128 B bis hinauf zu theoretischen 4 GB allokieren.
Wenn man das weiterführen würde, könnte man noch zusammenhängenden (hintereinanderfolgende) Speichereinheiten machen.

Du hast da einen Heap Tree, welcher den Heap beschreibt.
Dieser Heap Tree besteht aus Heap Segment Deskriptoren, von denen da der erste (top) vorhanden sein muss.
Dieser hat zwei Pointer welche zu weiteren Heap Segment Deskriptoren zeigen können, falls das Heap Segment zum Teil frei ist.
Der Status gibt also an wie und ob die Heap Segmente belegt sind und ob Pointer zum nächsten Heap Segment Deskriptor zeigt.

lg,

Toaster


Wird wie folgt bei TOS/Tin verwaltet:

Code: [Auswählen]

; Heap Segment descriptor:

; Offset Size Name content

; 00h dword HS Size         size of each Heap Segment
; 04h byte state the state of the Heap Segments
; 05h dword Pointer1 next Heap Segment descriptor pointer
; 09h dword Pointer2 next Heap Segment descriptor pointer


; state:

; high nibble low nibble
; yyyy xxxx
; 7654 3210
; 3210 3210

; the low nibble (xxxx) describes the first Heap Segment, the high (yyyy) the second

; each nibble is shared into 4 bits (3210):
; 0-1: 00 = full free
; 01 = partly free (=> Pointer points to next Heap Segment descriptor)
; 10 = reserved
; 11 = full used
; 2: reserved bit (1 = do not access Heap Segment or descriptor in any way [equal to preserved])
; 3: present (set if ~, cleared if not ~)


Mit einem Heap Tree kann man Speicher also sehr dynamisch verwalten, man kann dem Speicher sogar einen Status zuweisen (liegt in der Programmierung des Programmierers).

[bluecode]

toaster, dir ist schon klar, dass man zwischen dem allozieren von Pages und dem heap allocator (das was malloc/free/new/delete macht) unterscheiden sollte. Und hier war afaik nur die Pageverwaltung gefragt.
Erst letzteres muss mit dynamisch großen Speicherstücken umgehen, ersteres hab ich/wird im Allgemeinen unabhängig davon programmiert.

[MNemo]

( ich hoffe ihr versteht was ich meine )

Meinst du, dass du dein Stack nach der Adresse durchsuchen musst und dann die Adresse daraus entfernen? Ich würd solche Speicherbereich von vorneherein nicht in dem Stack speichern, sondern nur den Speicher, der wirklich frei verwendet werden kann.

genau das mein ich

ich habe mich nocht nicht so damit beschäftigt und habe gedacht, das ich beim system start noch nicht weiß, welsch speicher bereiche ich dafür benötige

[bluecode]

Du musst das anders herum sehen. Du weißt ja welche Bereiche benutzbar sind, das sagt dir zumindest irgendsoein BIOS-Int bzw. die Grub memory map. Außerdem solle man wahrscheinlich den Speicher unter dafür garnicht nutzen. Desweiteren befinden sich PCI devices normalerweise nicht im normalen RAM-Bereich, sondern viel weiter oben im Adressraum (genau wie die local bzw. I/O APIC).

[T0ast3r]

toaster, dir ist schon klar, dass man zwischen dem allozieren von Pages und dem heap allocator (das was malloc/free/new/delete macht) unterscheiden sollte. Und hier war afaik nur die Pageverwaltung gefragt.
Erst letzteres muss mit dynamisch großen Speicherstücken umgehen, ersteres hab ich/wird im Allgemeinen unabhängig davon programmiert.

sollen?

Ich verwalte den Speicher als Heap, und damit gibt's keine Probleme.

lg, gn8 und tsss....,

Toaster

[bluecode]

sollen?

jo, da das heap management normalerweise auch in der userspace app vorhanden ist, welche dann nur von der (im kernel vorhandenen) Pageverwaltung pages alloziert und das heap management dann selber übernimmt. Damit ist es möglich, dass jede app da das am besten passende Management implementiert (wie zB linked list, garbage collection, ....).

Aber das dein Bootmanager das nicht braucht, ist mir schon klar  

[bluecode]

um jetzt dann doch mal zum Thema zurückzukehren: Ich würde mir nochmal überlegen, ob du wirklich die Pageverwaltung auslagern willst, da es noch andere mögliche Designs mit Pager gibt: zB könntest du auch die Mechanismen (Funktionen) fürs Paging/Pageverwaltung im kernel lassen und dem Pager nur die Policy überlassen. Konkret soll das heißen, dass dein kernel zB folgende syscalls bereitstellt: registerPagefaultHandler & allocate/free/map/unmapPage [<-nur für den Pager aufrufbar], ipc. Anwendungen kommunizieren dann über ipc mit dem Pager, wenn sie speicher allozieren wollen und dieser benutzt dann die Kernelfunktionen (falls er die Anfrage für legitim hält).

hoffe, dass das so funktionieren könnte... ich hab nie daran gedacht meinen Kernel so stark zu reduzieren...