Thema: Kernelparts in Modulen unterbringen

[ChristianF]

Hallo Lowlevel-Community,
mir ist soeben eine fix Idee gekommen.
 
Und zwar möchte ich die Kernelaufgaben meines Microkernels in mehrere Module aufteilen. So hätte ich dann z.B. ein HAL-Modul, in dem Paging usw. definiert wird. Des Weiteren hätte ich noch eine Reihe von Einzelmodulen, wie z.B. eines für die physikalische Speicherverwaltung.
 
Ist so etwas praktikabel, oder sollte man das besser im Kernel belassen?
 
Gruß Christian

[kevin]

Die Frage ist, was genau du unter einem Modul verstehst. Da du von einem Mikrokernel redest, gehe ich davon aus, dass es was damit zu tun hat, den entsprechenden Code als eigenständigen Prozess auszuführen.

In Grenzen kann man natürlich auch manche Kernaufgaben aus dem Kernel rauswerfen, allerdings wird das dann wohl alles etwas tricky. Für einen Taskwechsel erst IPC mit dem Paging-Modul machen zu müssen, um den Speicherkontext zu wechseln, stelle ich mir jedenfalls nicht sehr praktisch vor.

Was willst du denn damit erreichen? Wenn es dir nur darum geht, auszuprobieren, ob es funktioniert, versuch es einfach. Ansonsten sehe ich aber nicht viel Nutzen darin - ein System z.B. ohne Speicherverwaltung ist ziemlich nutzlos. Und das Auslagern würde vermutlich massiv auf die Performance gehen.

[erik.vikinger]

Hallo,

Ist so etwas praktikabel, oder sollte man das besser im Kernel belassen?

Ich persönlich sage: las es im Kernel.
Sowas aus den Kernel raus zu verlagern bedeutet ne Menge spezielle Schnittstellen zu den einzelnen Services und mit Sicherheit auch ein deutlicher Performanceverlust. In einem Micro-Kernel sollten IMHO Speicherverwaltung (physisch und virtuell), Prozessmanagement (inklusive Scheduler), Timing (Events u.ä.) und IPC mindestens drin sein.
Wenn Du noch weiter abspecken möchtest, in Richtung Exo/Nano/Pico-Kernel, dann bedeutet das sicher auch ne Menge Arbeit. Wenn Dir der akademische Anspruch wichtig ist dann nur zu, ansonsten las es lieber.


Grüße
Erik

[ChristianF]

Eigentlich war das Modul nicht als eigenständiger Prozess gedacht.
 
Ich dachte mir das so, dass ich den Microkernel modularisiere, sprich es gibt ein Speichermanagementmodul. Über den Kernel springe ich bei Bedarf in den Code des Moduls und führe die entsprechend definierten funktionen aus.
 
Was ich mir gedacht habe, war einfach nur das Auslagern von Code aus dem Kernel, aber halt als Code, der vom Kernel aufrufbar ist und nicht als eigenständige Treiber.

[bluecode]

Es macht aber eigentlich dann keinen Sinn das von der Kerneldatei zu trennen. Ist nur zusätzlicher Aufwand ohne Gewinn. Eine gute Trennung in Teile mit klar definierten Schnittstellen ist da wohl eher das was du möchtest. Aber das ist ja alles nur in der Sourcecodeform sichtbar und am Ende zusammen in einer Binary.

[DaCodaaa]

Also für mich ist jetzt nicht ersichtlich wer jetzt das Multitasking-Modul managed. Also ich meine, das will ja irgendwie aufgerufen werden um dann andere Prozesse zu managen, aber wer managed dann den Manager des Managers? Folglich muss Multitasking schonmal in den Kernel. Und um Multitasking zu initialisieren muss das Modul ja wissen wo es seinen Speicher hat, also braucht es einen Speichermanager. Den könnte man ja theoretisch im Kernel implementieren und nach dem initialisieren in einem Modul weiterlaufen lassen, aber bis auf einen Performanceverlust und Komlizierterem code wirst du dann keine Unterschiede feststellen...

Ich denke, wenn du schauen willst ob es geht dann viel Spass! Sonst lass es lieber.

[FlashBurn]

Ich kram den Thread einfach mal wieder aus. Ich bin mir nicht sicher ob ich verstanden habe was Du (=ChristianF) meinst, aber ich mache in meinem Kernel folgendes.

Ich habe bestimmte Sachen in "Module" gesteckt (z.b. PMM, IRQs usw.). Diese "Module" implementieren ein bestimmtes Interface. Mein Loader linkt dann all diese "Module" mit dem "Kernel-Modul" zusammen. So weit so sinnlos

Was will ich aber damit erreichen?!

Der Punkt ist, ich kann/will erst zur Laufzeit wissen ob der PC z.b. nen LAPIC hat oder nen IO-APIC usw. Was ich jetzt nicht will ist das der Code für diese ganze Hardware mit dem Kernel geladen wird und ich dann halt zur Laufzeit nur ein paar Funktionspointer umhänge (1. indirekte Aufrufe und 2. bleibt der Code ja im Speicher = Overhead).

Mein Kernel liegt mit samt seinen Modulen in einem Tar-Archive und der Loader guckt halt auf was für Hardware er läuft und linkt dann die entsprechenden Module zusammen und die "nutzlosen" Module können wieder freigegeben werden. So habe ich z.b. 3 verschieden PMMs, habe bei bestimmten Sachen unterschiedlichen Code für SMP und ein CPU Systeme und ich habe 2 verschiedene Module für IRQs (PIC und IO-APIC) und 2 (jedenfalls noch) verschiedene Scheduler (einmal SMP und einmal 1 CPU).

Wenn du sowas meintest, dann ja ist möglich und auch nicht wirklich sinnlos.

Drauf gekommen bin ich eigentlich darüber, dass ich es möglich machen wollte das der Kernel zur Laufzeit gepatcht werden kann und dafür brauche ich halt die ganzen Link Infos, aber das war mir dann nachher doch zu komplex und ich habe dann den schon vorhandenen Code einfach dafür genutzt.

[ChristianF]

An ein ähnliches Konstrukt habe ich auch gedacht. 
 
Wenn ich dein Konstrukt verwenden würde, müsste ich mir aber auch einen extra Loader schreiben, oder GRUB anpassen, oder eben einen zusätzlichen Kernel dazwischen schieben...
 
Momentan komme ich aber zu nix, da die Abschlussprüfungen ins Haus stehen und ich, um für den schriftlichen Part zugelassen zu werden, ein Projekt durchgeführt haben muss.
 
Vielleicht komme ich in der Zeit nach meiner Ausbildung, wenn ich meinen Zivildienst leiste wieder zu etwas mehr...