Wie kommunizieren Programme mit Treibern?



  • Danke für eure Antworten.

    Allerdings wollte ich noch fragen: Die "unterste" Ebene ist doch stets das BIOS, oder? D.h. eigentlich kommuniziert nur das BIOS mit der Hardware, die Programme/API/Treiber kommunizieren nur mit dem BIOS, wenn ich das so richtig verstanden habe?



  • ------------------------- schrieb:

    Allerdings wollte ich noch fragen: Die "unterste" Ebene ist doch stets das BIOS, oder? D.h. eigentlich kommuniziert nur das BIOS mit der Hardware, die Programme/API/Treiber kommunizieren nur mit dem BIOS, wenn ich das so richtig verstanden habe?

    Nope, in einem modernen Betriebssystem redet Driver bzw. das Betriebssystem mit der Hardware...



  • dot schrieb:

    ------------------------- schrieb:

    Allerdings wollte ich noch fragen: Die "unterste" Ebene ist doch stets das BIOS, oder? D.h. eigentlich kommuniziert nur das BIOS mit der Hardware, die Programme/API/Treiber kommunizieren nur mit dem BIOS, wenn ich das so richtig verstanden habe?

    Nope, in einem modernen Betriebssystem redet Driver bzw. das Betriebssystem mit der Hardware...

    Ja, und der Treiber (="Driver") redet wiederrum mit dem BIOS.

    Wie soll es denn sonst gehen?
    Der Treiber, bzw. das Betriebssystem ist Software, d.h. man braucht eine Schnittstelle zwischen Hardware und Software, und die einzige Schnittstelle, die mir bekannt ist, ist das BIOS.



  • ------------------------- schrieb:

    Ja, und der Treiber (="Driver") redet wiederrum mit dem BIOS.

    Nope.

    Wie soll es denn sonst gehen?
    Der Treiber, bzw. das Betriebssystem ist Software, d.h. man braucht eine Schnittstelle zwischen Hardware und Software, und die einzige Schnittstelle, die mir bekannt ist, ist das BIOS.

    Das BIOS ist auch bloß Software. Software redet mit Hardware über Mechanismen wie Memory-Mapping, IO-Ports und Interrupts. Das alles zu erklären, führt jetzt zu weit, ich weiß jedenfalls nicht, wieweit ich ausholen soll. Frag ggf. nach.



  • Was passiert wenn du deinen PC einschaltest? Woher weiß die CPU, was sie jetzt tun soll? Die CPU ist hardwired, sobald sie Strom bekommt, das Programm auszuführen, das an einer ganz bestimmten Adresse zu finden ist. Dein PC ist so gebaut, dass diese Adresse zum Zeitpunkt des Einschaltens in das BIOS ROM mapped. Das BIOS ist nichts anderes als das erste Programm, das von der CPU ausgeführt wird. Das ist alles. Hinter dem BIOS verbirgt sich keine Magie; das BIOS ist ein Programm für die CPU wie jede andere Software auch.



  • dot schrieb:

    Was passiert wenn du deinen PC einschaltest? Woher weiß die CPU, was sie jetzt tun soll? Die CPU ist hardwired, sobald sie Strom bekommt, das Programm auszuführen, das an einer ganz bestimmten Adresse zu finden ist. Dein PC ist so gebau, dass diese Adresse zum Zeitpunkt des Einschaltens in das BIOS ROM mapped. Das BIOS ist nichts anderes als das erste Programm, das von der CPU ausgeführt wird, das ist alles. Hinter dem BIOS steckt keine spezielle Magie, das BIOS ist ein Programm für die CPU wie jede andere Software auch.

    Ja, das BIOS lädt die ersten 512 bytes von der Festplatte und führt sie aus.

    Ich versteh bloß nicht, wie genau Software mit Hardware kommunizieren.



  • ------------------------- schrieb:

    Ja, das BIOS lädt die ersten 512 bytes von der Festplatte und führt sie aus.

    Unter anderem, ja.

    ------------------------- schrieb:

    Ich versteh bloß nicht, wie genau Software mit Hardware kommunizieren.

    Über memory-mapped I/O, I/O Ports und Interrupts...



  • Kann man diese I/O-Ports auch im Real-Mode ansprechen?



  • Ja, natürlich. Dazu sind die Befehle IN und OUT da.



  • Was für Befehle sind das genau?
    IN und OUT als Assembler-Mnemonics?



  • Ja, natürlich. Wenn wir darüber reden, wie der Prozessor mit der Peripherie kommuniziert, werden das wohl kaum Shell-Befehle sein ...



  • Bashar schrieb:

    Ja, natürlich. Wenn wir darüber reden, wie der Prozessor mit der Peripherie kommuniziert, werden das wohl kaum Shell-Befehle sein ...

    Ok, wahrscheinlich nutzt jedes Gerät einen anderen Port, sodass für jeden ****** extra was implementiert werden muss?



  • ------------------------- schrieb:

    Ok, wahrscheinlich nutzt jedes Gerät einen anderen Port, sodass für jeden ****** extra was implementiert werden muss?

    ...und genau daher gibt es Driver und APIs: Damit du ein einheitliches Interface verwenden kannst, um mit jedem ****** zu reden, ohne den ganzen ****** dauernd neu schreiben zu müssen...



  • Kann ich IN und OUT unter Linux (in einem ganz normalen Programm) nutzen?

    Und anscheinend implementieren dann die Treiberentwickler die ganzen Portnummern?!

    so nach dem prinzip:

    switch(geraet) {
           case GERAET1:  port=1; break;
           case GERAET2:  port=12345; break;
    // ...
    


  • ------------------------- schrieb:

    Kann ich IN und OUT unter Linux (in einem ganz normalen Programm) nutzen?

    Die Befehle sind privilegiert, ohne weiteres geht das also nicht. Aber unmöglich ist es auch nicht:
    http://www.tldp.org/HOWTO/IO-Port-Programming.html

    Und anscheinend implementieren dann die Treiberentwickler die ganzen Portnummern?!

    Die Portnummern sind nicht das Problem, sondern das Verhalten der Hardware, also quasi das Protokoll.



  • Wo finde ich diese Herstellerdokumentationen?

    Ich hab Hardware von mit gegoogelt, konnte aber weder die Portnummer noch irgendwelche Befehlsreferenzen finden.



  • ------------------------- schrieb:

    Wo finde ich diese Herstellerdokumentationen?

    Das hängt von Hardware und Hersteller ab. Intel veröffentlicht meist sehr detaillierte Manuals. Andere Hersteller veröffentlichen oft nichts dergleichen, Betriebsgeheimnis und so...



  • ... Und woher wissen dann die Treiber-Programmierer, welche Ports und Befehlssätze ein bestimmtes Gerät nutzt?

    "Betriebsgeheimnis"? 😕



  • ------------------------- schrieb:

    ... Und woher wissen dann die Treiber-Programmierer, welche Ports und Befehlssätze ein bestimmtes Gerät nutzt?

    Driver werden in der Regel von den entsprechenden Herstellern zur Verfügung gestellt...



  • dot schrieb:

    ------------------------- schrieb:

    ... Und woher wissen dann die Treiber-Programmierer, welche Ports und Befehlssätze ein bestimmtes Gerät nutzt?

    Driver werden in der Regel von den entsprechenden Herstellern zur Verfügung gestellt...

    Linux?

    Vielleicht ist das der Grund, warum mein CD-Laufwerk unter Linux nicht zu 100% unterstützt wird.


Anmelden zum Antworten