Thema: was gehört in einen kernel?

[Jidder]

Prozessorspezifische Dinge sind eigentich nichts, was man gut in einem Treiber verpacken könnte. Es gehört ja mehr dazu als nur das Feature zu aktivieren.

Ein Treiber stellt ja normalerweise irgendwelche Funktionen bereit um ein Gerät zu lesen, zu beschreiben, bunte Pixel auf den Bildschirm zu kopieren oder krasse Gitarrenriffs aus den Boxen erschallen zu lassen. Das heißt ein Programm hat dann auch irgendwo einen Aufruf der Funktion FileOpen, DrawPixel oder PlaySound.

Im Fall von prozessorspezifischem Zeug wären die Treiberaufrufe hauptsächlich im Kernel, weil es ja um sehr sensible Geschichten wie Speicherverwaltung (PAE, PSE, ...), Ausführungsprivilegien (NX-Bit), Virtualisierung, und so weiter geht. Das heißt jedes unterstützte Feature benötigt zwingend auch Modifikationen im Kernel. Diese Sachen sind aber auch alle so speziell, dass diese in sehr vielen Bereichen hineinspielen. Du müsstest deswegen quer über den Kernel verteilt diese Treiberfunktionen aufrufen. Und da hast du dann immer das Problem, dass du wieder if-Abfragen in dieser Form hast:

Code: [Auswählen]

if (pae_enabled()) { 
 pae_treiber_do_something();
} else {
 default_do_something();
}Das bläst deine Kernelfunktionen genauso auf, als hättest du alles gleich im Kernel gelassen. Nur die Performance ist schlechter

Wenn du deine Kernel mehr oder weniger minimalistisch halten willst, kannst du deinen Kernel möglichst weit modularisieren (ähnlich wie du es beim Treiber gemacht hättest), dann aber trotzdem den Code direkt in den Kernel zu linken. Wenn du zum Beispiel Prozessoren mit und ohne PAE optimal unterstützen willst, kannst du zwei Kernel aus den selben Sourcen kompilieren, und PAE- und nicht-PAE-spezifische Teile mittels #define und #ifdef trennen.

[ChristianF]

Wenn du deine Kernel mehr oder weniger minimalistisch halten willst, kannst du deinen Kernel möglichst weit modularisieren (ähnlich wie du es beim Treiber gemacht hättest), dann aber trotzdem den Code direkt in den Kernel zu linken. Wenn du zum Beispiel Prozessoren mit und ohne PAE optimal unterstützen willst, kannst du zwei Kernel aus den selben Sourcen kompilieren, und PAE- und nicht-PAE-spezifische Teile mittels #define und #ifdef trennen.

Das wäre dann natürlich auch eine Option.
 

Im Fall von prozessorspezifischem Zeug wären die Treiberaufrufe hauptsächlich im Kernel, weil es ja um sehr sensible Geschichten wie Speicherverwaltung (PAE, PSE, ...), Ausführungsprivilegien (NX-Bit), Virtualisierung, und so weiter geht. Das heißt jedes unterstützte Feature benötigt zwingend auch Modifikationen im Kernel. Diese Sachen sind aber auch alle so speziell, dass diese in sehr vielen Bereichen hineinspielen. Du müsstest deswegen quer über den Kernel verteilt diese Treiberfunktionen aufrufen. Und da hast du dann immer das Problem, dass du wieder if-Abfragen in dieser Form hast:

Code: [Auswählen]

if (pae_enabled()) { 
 pae_treiber_do_something();
} else {
 default_do_something();
}Das bläst deine Kernelfunktionen genauso auf, als hättest du alles gleich im Kernel gelassen. Nur die Performance ist schlechter

Das nicht unbedingt. Gedacht hatte ich das so, dass Paging und so zeug auf Basis i386 implementiert werden. Sobald dann der Systemtreiber geladen wurde (falls vorhanden) wird die Speicherverwaltung im Kernel abgeschaltet. Das würde dann aber auch wieder einige if-Abfragen benötigen...
 
 
Dann werde ich das ganze wohl über Module machen...