Autor Thema: Treiber und Kernel  (Gelesen 14724 mal)

woigl

  • Beiträge: 93
    • Profil anzeigen
    • http://www.nogos.org
Gespeichert
« am: 21. August 2005, 08:10 »
Wenn ich z.b.: einen Tastaturtreiber fuer PS2, einen fuer USB schreibe habe ich ja verschiedene Treiber die ich dann nicht immer alle brauchen werde. Somit sollten die Treiber dynamisch geladen werden.

1.) Wie stelle ich dies am besten an?

2.) Wenn sie dznamisch geladen werden wie kommunizieren die Treiber mit dem Kernel?

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #1 am: 21. August 2005, 10:17 »
Wieder stellt sich die Frage nach dem Aufbau.

Beim monolithischen Kernel lädst du die Treiber als Module (also praktisch ELF-Objektdateien) nach, und linkst die in den Kerneladdressraum rein. Damit wird aus der Kommunikation einfache Funktionsaufrufe.

Beim Microkernel ist ein Treiber ein Prozess. Damit brauchst du Interprozesskommunikationsmöglichkeiten bevor du Treiber implementieren kannst.
*post*

woigl

  • Beiträge: 93
    • Profil anzeigen
    • http://www.nogos.org
Gespeichert
« Antwort #2 am: 21. August 2005, 11:07 »
Zitat von: Legend
Wieder stellt sich die Frage nach dem Aufbau.

Beim monolithischen Kernel lädst du die Treiber als Module (also praktisch ELF-Objektdateien) nach, und linkst die in den Kerneladdressraum rein. Damit wird aus der Kommunikation einfache Funktionsaufrufe.

Beim Microkernel ist ein Treiber ein Prozess. Damit brauchst du Interprozesskommunikationsmöglichkeiten bevor du Treiber implementieren kannst.


Okay - also ich denke mal monolithisch wie Linux - da ich schon viel negatives über Microkernel gehört habe.

Also wenn Linux es so macht mit den ELF Objektdateien - wo gibts ein Tutorial oder Hilfe zu dem?

woigl

  • Beiträge: 93
    • Profil anzeigen
    • http://www.nogos.org
Gespeichert
« Antwort #3 am: 21. August 2005, 16:20 »
Zitat von: Legend
Wieder stellt sich die Frage nach dem Aufbau.

Beim monolithischen Kernel lädst du die Treiber als Module (also praktisch ELF-Objektdateien) nach, und linkst die in den Kerneladdressraum rein. Damit wird aus der Kommunikation einfache Funktionsaufrufe.

Beim Microkernel ist ein Treiber ein Prozess. Damit brauchst du Interprozesskommunikationsmöglichkeiten bevor du Treiber implementieren kannst.


Wenn wir nochmals zum linken zurückkommen - wie ist das gemeint - zur Laufzeit reinlinken oder dann beim Kernel Start dazu linken (wobei ich mir das nicht vorstellen kann).

Verstehe ich das richtig das Linux dann alles (Filesysteme, Soundtreiber, usw.) Alles im Kernel mitgelinkt hat?

Noch eine Frage: Also nehmen wir mal den fopen() her, welcher mir eine Datei öffnen und ich mit einem Stream zurgreifen kann. Der Festplattentreiber ist im Kernel, und der fopen wird aus einem Programm verwendet, wie kommuniziert das ganze miteinander? Ich denke das mir da was an Wissen fehlt.

SSJ7Gohan

  • Beiträge: 398
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 21. August 2005, 17:08 »
Wie du ELF Relocateables relocatest findest du in deinem eigenen Thread: http://www.lowlevel.brainsware.org/forum/viewtopic.php?t=907

Eigentlich ist das ganze kein dynamisches Linken, unter dynamischem Linken versteht man eher das linken von shared objects zu einem Programm und das ist im Vergleich zum relocieren sehr schwierig.

Vor dem Problem wie ich Treiber einbinde stehe ich im Moment auch, eigentlich wollte ich sie als shared objects implementieren, die dann in den Prozess der sie benutzt gemappt werden, das ist aber relativ schwer zu implementieren. (Wenn jemand ein Tutorial oder Beispielcode für das laden von shared objects hat, wäre ich sehr dankbar^^)

Mein Hybrid-Kernel unterstützt es bisher, Treiber als Prozesse zu laden und dann in den Treiber zu springen, indem der Prozess gewechselt wird und die Parameter des Funktionsaufrufes vom einen Addressspace in den anderen gemappt werden. Das ist aber relativ lahm. Ausserdem unterstütze ich noch eine Exokernel ähnliche Treiberart, nähmlich, das der User selbst die Hardware nutzen kann. Das ist aber nur begrenzt möglich, da man nicht kontrollieren kann, was genau der user mit der Hardware macht. Festplatten brauchen z.B. einen eigenen Treiber, damit nicht jeder Benutzer alle Daten verändern kann. LegendOS hat/hatte eine Technik namens migrating threads, die könnte ich mir mal ansehen.^^

Wäre nett, wenn mir jemand erklären könnte, wie migrating threads funktionieren.

woigl

  • Beiträge: 93
    • Profil anzeigen
    • http://www.nogos.org
Gespeichert
« Antwort #5 am: 21. August 2005, 17:13 »
Ja damit komm ich schon weiter, DANKE! Trotzdem ein Aufruf an alle - helft bei den Tutorials - es fehlen noch so viele Dinge...

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #6 am: 21. August 2005, 18:24 »
Nun ja, im wesentlich gab es bei LegendOS einen Syscall, der Parameter kopiert und den Prozess wechselt, so dass die Programme sich das nicht mit mehreren Syscalls zusammenbauen müssen.
*post*

SSJ7Gohan

  • Beiträge: 398
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 21. August 2005, 21:26 »
Wie sieht denn das Migrating Threads Konzept aus?

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #8 am: 21. August 2005, 22:36 »
*post*

 

Einloggen