Thema: [suche] Micorkernel tutorial

[Kevin_]

Hallo,
Ich suche in Tutorial zu Microkernel. Ich ahbe im Momment keine Ahnung wie das mit der Komunikatio nzwischen den Servern und dem Kernel funktionieren soll etc.
Gruß Kevin

[Roshl]

Naja einen direkten "So muss mans machen" Artikel wirds dazu nicht geben. Nirgendswo anders als im OS-Dev hast du mehr Möglichkeiten etwas umzusetzten wie mans macht hängt letztendlich von den eigenen Ideen und Fähigkeiten ab. Wenn ich jetzt ganz spontan ne Idee auswerfen müsste dazu hätte ich folgendes:
Jeder Server läuft ja als eigenständiger Task, wenn der Kernel nun etwas von einem Server will, packt der Daten auf einen Stack (halt ein Spezieller "Aufgabenstack") eben dieses Servers, der dann abgefragt und abgearbeitet wird wenn der Server wieder dran ist.
Wäre mal jetzt so ne kleine Idee, wie mans letztendlich umsetzt würde bei jedem selbst liegen, auch obs nun ne sonderlich gute Idee ist weiß ich nicht^^

[TeeJay]

Also jedem Server musst du wie Roshl sagte nen eigen Process (Task) geben.

Für jeden Task solltest du (so oder so) einen extra Speicherbreich erstellen über den er sogenannte Messages erhalten kann. Sprich Datenwerte können dort von jedem anderen Task abgelegt werden und der betreffende Task liest diese dann und verarbeitet diese.

[GhostCoder]

Hiho,

also, Pages mit allen Prozessen zu teilen, find ich keine gute Idee, da ein guter(schlecher) Prozess sich dann im Queue direkt auf Platz 1 setzen kann, und andere Messages löschen kann.

Eine bessere Idee finde ich ist:
Verbindet ein Client zum Server, wird ne (physikalische) Page reserviert, und bei beiden Prozessen auf eine (bzw. zwei, bei jedem Prozess ne andere) virtuelle Page gemappt. So können die beiden schonmal Daten austauschen.
Das eigentliche Messaging würde ich über Register realisieren!

Als Beispiel:
Client connected auf Server, und schickt ne Message, in der steht, "schreibe in die datei x 123 bytes". Die eigentlichen Daten liegen dann in der shared page.

Aber nochwas,
ein Microkernel ist echt eine schwere Aufgabe, du musst bedenken, der Kernel darf nichts anderes als Speicherverwaltung,Prozessverwaltung (Threads sind auch wichtig!) und Scheduling. Bis du da was am Bildschirm siehst, dauert es echt lange (kann da aus Erfahrung sprechen). Wenn du Anfänger bist, fang leiber mit einem Monolitischen Kernel an!

MfG GhostCoder

[Roshl]

Im Prinzip hab ich genau das gesagt^^
Da die gesamte Architektur der x86 Familie stark auf Stack gebrauch ausgerichtet ist (und der somit auch schnell ist) versuche ich viel mit Stack zu erledigen

[Kevin_]

Also müsste der Kernel schon Multitasking fähig sein oder?

[Roshl]

Wenn nicht gar Multithreading^^ aber Multitasking ist da unumgänglich

[GhostCoder]

Kevin,
Ziel eines Microkernels ist es, jeden möglichen Code aus den Kernel in einen seperaten Prozess unterzubringen.
Also, ich sag nur: Monolithischer Kernel

Roshl,
das hätte ich jetzt auch gesagt
Multithreading ist auch wichtig, forken bremst einen Microkernel extrem aus, außerdem keine Unix Systemcalls!

MfG GhostCoder

[Roshl]

Ist eigentlich alles reine Implementierungssache.
Wie meinste das mit keine Systemcalls?
Ich hab nen Syscall z.B. für alles was grafik ist über Int 0x40 gemacht, will ein Programm nen Dreieck gezeichnet haben 3mal x und y koordinaten und die farbe auf den stack (als 32Bit-Wert in RGB, wird dann intern umgewandelt jenach aktueller Farbtiefe) mov ax,3 int 0x40 und dann wird ein Dreieck gezeichnet^^ Der Int hat mindest Privileg 1 also kann auch nicht jedes Progg das machen^^

[GhostCoder]

Hiho,

ich meinte keine Unix Systemcalls, weil die alle syncron sind.

z.B.: Ein Programm will den Unix fork() Systemcall ausführen:
Systemcall springt in den Kernel, "führt" den fork code aus, und springt zurück. Währenddessen wartet das ganze System. Sowas sollte bei einem Microkernel nicht sein!
Besser ist, während eines timeslices (aktivierung per scheduler bis aufruf timer interrupt) Die Systemcalls zu sammeln, und dann vom Scheduler an die passenden Prozesse schicken zu lassen.

Es macht für ein Programm ja keinen Unterschied ob seine Dreiecke in dem Moment des "int 0x80" gezeichne werden, oder beim timerinterrupt(bzw. aufruf des video daemons), hauptssache die reihenfolge bleibt. Da lassen sich dann auch gute Prioritätensystem entwickeln, wenn z.b. ein server 2000 messages im queue hat, aber erst in 10 slices ausgeführt werden sollte(mit round-robin) kann man den auch eher ausführen.

Guten Beispiel sind die Win32 Async Winsock Funktionen, oder ReadFileEx und sowas. Alles asyncrone API.

MFG GhostCoder