Thema: CDI und Monolith

[OsDevNewbie]

Hallo liebe OSEntwickler,

da ich an dem Punkt angekommen bin, an dem ich mich entscheiden muss was für ein Kernel mein Kernel wird, habe ich mich für einen monolithischen Kernel entschieden (oder sowas ähnliches wie Windows). Nun würde ich gerne CDI als Schnittstelle zu meinen Treibern benutzen und wenn möglich auch die schon vorhandenen Treiber verwenden. Ist das denn möglich? Wenn ja, was muss ich beachten bzw. was muss ich tun damit dies funktioniert. Ist die Spezifikation, die im Wiki gegeben ist aktuell? Und wo finde ich die schon vorhandenen Treiber für diese Schnittstelle? Ich muss die doch ein bisschen umschreiben, da sie doch für Tyndur (ein Exokernel) entwickelt wurden oder?

Ich danke euch schon im Voraus für eure Hilfe.

[kevin]

Zuerst einmal der Link zum git-Repository: http://git.tyndur.org/?p=cdi.git;a=summary

Was dort in den Kommentaren der Headerdatei steht, ist auf jeden Fall die aktuelle Version der Dokumentation. Es gibt aber auch noch http://lpt.tyndur.org/cdi/ als Online-Ausgabe davon (nicht sicher, wann es zuletzt aktualisiert worden ist, aber es dürfte nicht viel schlechter sein).

Die Treiber sind nicht speziell für tyndur entwickelt worden, sondern für CDI. Letztendlich besteht der Standard aus einem Satz von Headerdateien, die von den Treibern benutzt werden. Damit du die Treiber auf deinem OS benutzen kannst, musst du die Funktionen in diesen Headerdateien implementieren. Außerdem ist include/cdi-osdep.h zum Verändern vorgesehen, dort kannst du OS-spezifische Details eintragen. Der komplette Unterschied zwischen einen Mikrokernel wie tyndur und einem Monolithen ist hinter diesem Interface versteckt, es spielt für die Treiber keine Rolle.

Wichtig ist dort vor allem das Makro CDI_DRIVER(), mit dem sich Treiber bei deinem OS registrieren, so dass du hinterher alle Treiber durchgehen und initialisieren kannst. Dieser Teil ist ein bisschen tricky, evtl. willst du dir da von tyndur die cdi-osdep.h und cdi_init() in cdi.c anschauen.

Ich würde zum Portieren von CDI von zwei Seiten anpacken: Zum einen würde ich mir einen bestimmten Treiber raussuchen, den ich haben möchte, und versuche ihn einfach zu kompilieren und linken, und bei fehlenden Funktionen würde ich die implementieren (die meisten Treiber brauchen nur einen kleinen Teil der Funktionen, die in den Headern definiert sind, deswegen dieser Ansatz). Wenn das dann tut, also Treiber gegen deine CDI-Implementierung bauen, würde ich mit dem Kernel anfangen, dass er die registrierten Treiber findet, die init-Funktionen aufruft, PCI-Geräte an Treiber verfüttert usw.

[OsDevNewbie]

Erstmal danke für deine Antwort.

Dann habe ich trotzdem noch eine Frage, nämlich wie kann man dann so ein Modul linken? Muss man die CDI-Headers sozusagen als Lib einbinden oder wie geht das? Woher weiss der Linker, wo im Kernel sich die Funktionen finden? Ich dachte man muss der Initialisierungsroutine des Treibers eine Liste der Funktionen übergeben anders kann ich mir nichts vorstellen, wie das gehen soll.

[kevin]

Bei einem monolithischem Kernel linkst du die Treiber einfach alle in den Kernel mit rein, das gibt ja keine eigenständigen Binaries. Also genauso wie du vermutlich verschiedene Objektdateien für Speicherverwaltung, Scheduler und Interrupthandling reinlinkst, linkst du eben auch noch die Dateien des IDE-Treibers (oder was auch immer du benutzen willst) mit rein.

[OsDevNewbie]

Ok danke für deine Hilfe.

Zuerst aber muss ich meine Speicherverwaltung in Ordnung bringen, denn ich habe dort eine monströse Fehlerquelle entdeckt.

[OsDevNewbie]

So jetzt habe ich trotzdem noch eine Frage nur um sicher zu gehen: In den Ordnern des cdi-gits befinden sich doch die Treiber, ich in meinen Kernel linken muss oder?

[kevin]

Ja, die Treiber und die Headerdateien, die das Interface spezifizieren.

[OsDevNewbie]

Gibt es denn eine Möglichkeit einen ganzen Ordner oder nur einzelne Dateien runterzuladen?

[kevin]

Du kannst im Webinterface den Link "snapshot" benutzen, der dann das Verzeichnis, das du gerade anschaust (oder in der Commitlog das komplette Repository), als .tar.gz exportiert.

Am einfachsten ist es aber wahrscheinlich, mit git clone git://git.tyndur.org/cdi.git das komplette Repository per git zu holen.

[OsDevNewbie]

Danke für deine bisherige Hilfe kevin.
Ich habe trotzdem noch Fragen.

Ist es denn in einem Monolithen wirklich nötig cdi_Init() jedes mal beim Treiber initialisieren aufzurufen?
Oder was bringt die Funktion ata_init() eigentlich genau?

Ich dachte DMA ist alt und ist in neueren Computer nicht mehr überall vertreten. Warum benutzt denn der ATA-Treiber dann DMA? Kann man dies auch irgendwie abschalten, da ich meine Speicherverwaltung dafür nicht ausgelegt habe.

Danke vielmals.

[Svenska]

Ich dachte DMA ist alt und ist in neueren Computer nicht mehr überall vertreten. Warum benutzt denn der ATA-Treiber dann DMA? Kann man dies auch irgendwie abschalten, da ich meine Speicherverwaltung dafür nicht ausgelegt habe.

Die alte Technologie heißt ISA-DMA und basiert darauf, dass ein DMA-Controller den Bus übernimmt und Daten von einem Gerät* in ein anderes kopiert, ohne die CPU zu belasten.
Die neue Technologie heißt Busmaster-DMA und basiert darauf, dass ein Gerät selbst den Bus übernimmt und Daten von einem anderen / in ein anderes Gerät(*) kopiert, ohne die CPU zu belasten. Damit erspart man sich den DMA-Controller.

Nicht alle Geräte unterstützen den Betrieb komplett ohne DMA. Bei IDE sollte es aber möglich sein - ist dann halt sehr langsam und blockiert die CPU beim Festplattenzugriff.

*: Eins der Geräte bei einem DMA-Transfer ist üblicherweise der RAM.

[OsDevNewbie]

So jetzt habe ich trotzdem nochmal eine Frage:
Welche Funktion(en) des Treibers (ATA) muss ich jetzt aufrufen um ihn zu initialisieren?

Danke.

[kevin]

Eigentlich nur die .init-Funktion aus der struct cdi_driver. Letztendlich also driver_storage.drv.init und driver_scsi.drv.init.

Am geschicktesten machst du das, indem du das Makro CDI_DRIVER() in cdi-osdep.h so definierst, dass es Pointer in einer speziellen Section ablegt, die du dann bei deiner Kernelinitialisierung als Array aller Treiber behandeln kannst. Dann gehst du da in einer Schleife drüber und rufst von allen .init() auf.

[OsDevNewbie]

Muss ich denn nicht einfach cdi_init() aufrufen und dieses macht dann das, was kevin beschrieben hat?

[kevin]

Ja. Der Haken dabei ist, dass du diese cdi_init() selber schreiben musst.

(Gut, du kannst sie auch bei einem anderen OS klauen, aber im offiziellen CDI-Repo ist sie nur im Header deklariert, nicht implementiert.)

[OsDevNewbie]

Ich habe jetzt noch den iso9660-Treiber implementiert. Jetzt sind noch ein paar Fragen aufgetaucht.
Habe ich das richtig verstanden, dass die Funktion cdi_fs_data_read() einen oder mehrere Sektoren vom entsprechenden Gerät liest, auf das dieses Dateisystem ist? Also z.B. von einem ATA-Gerät?
Ich habe in der Dokumentation von einer Funktion namens "cdi_driver_run()" oder so ähnlich gelesen. Ich kann diese aber nirgendwo im cdi-Header (cdi.h) finden.
Und wie finde ich jetzt heraus, welche Treiber für welche Geräte zuständig sind? In der cdi_driver Struktur gibt es eine Funktion namens "init_device. Diese wird aber von keinem Treiber gesetzt. Für was ist dann diese Funktion da?

Ich hoffe ihr könnt mir meine Fragen beantworten. Ich stehe momentan so ziemlich auf dem Schlauch. Ich weiss nicht was ich jetzt damit machen soll.

[OsDevNewbie]

Weiss niemand etwas?

[Svenska]

Hallo,

Und wie finde ich jetzt heraus, welche Treiber für welche Geräte zuständig sind?

Indem du zum Beispiel die gefundenen Geräte mit einer Liste abgleichst, in der zu jedem Gerät ein Treiber angegeben ist. Dabei kann es übrigens auch zu Mehrdeutigkeiten kommen: Ein spezieller Grafiktreiber ist natürlich optimal, aber ein VESA-Treiber ist auch gut. Aber der VGA-Treiber wird vermutlich auch funktionieren. Manche Netzwerkkarten sind zueinander auch kompatibel.

Linux hat in jedem Kernelmodul drin stehen, für welche Geräte dieses Modul zuständig ist (auch mit Wildcards).

Gruß,
Svenska

[XanClic]

Habe ich das richtig verstanden, dass die Funktion cdi_fs_data_read() einen oder mehrere Sektoren vom entsprechenden Gerät liest, auf das dieses Dateisystem ist? Also z.B. von einem ATA-Gerät?

Ja. Um welches Gerät/welche Datei es geht (die also gemountet ist), speichert das OS (bzw. die CDI-Bibliothek) normalerweise irgendwie in cdi_fs_filesystem.osdep.

Ich habe in der Dokumentation von einer Funktion namens "cdi_driver_run()" oder so ähnlich gelesen. Ich kann diese aber nirgendwo im cdi-Header (cdi.h) finden.

Öffa, ich glaube, die Funktion ist veraltet. Heute geht man halt alle Treiber durch, die man hat, und ruft da jeweils die init-Funktionen auf (ich persönlich scheine das nicht zu machen, aber das schiebe ich jetzt mal auf Unvermögen meinerseits) und registriert die Treiber beim System (per cdi_foo_driver_register). Wenn dann ein Gerät reinkommt, ruft man bei allen (vom Typ und Bussystem her in Frage kommenden) Treibern die init_device-Funktion auf, die testet, ob das Gerät kompatibel ist. So viele Treiber gibts bei CDI ja (noch) nicht, da kann man das schon so machen. 

[OsDevNewbie]

Wenn dann ein Gerät reinkommt, ruft man bei allen (vom Typ und Bussystem her in Frage kommenden) Treibern die init_device-Funktion auf, die testet, ob das Gerät kompatibel ist. So viele Treiber gibts bei CDI ja (noch) nicht, da kann man das schon so machen. 

Aber wie soll ich diese aufrufen können, wenn die von keinem Treiber gesetzt wird?