Wie kommunizieren Programme mit Treibern?

Hallo,

wie kommunizieren Programme mit Treibern?

Ich meine, wenn Programme (z. B. Browser) auf das Internet zugreifen, dann nutzen sie wahrscheinlich einfach die von der System-API bereitgestellten Funktionen (Sockets usw.).

Was machen diese Funktionen genau, bzw. wie arbeiten sie?
Ist es möglich, auch ohne diese APIs direkt mit einem Treiber zu kommunizieren?

DeviceIoControl function

Sends a control code directly to a specified device driver, causing the corresponding device to perform the corresponding operation.

Ok, aber das scheint auch mit der Windows API zusammenzuhängen, aber ich wollte ja eben, dass keine API benutzt wird.

Aber wenigstens die Frage, was diese Windows-Funktionen aus der API machen, scheint geklärt. Die senden einen Code an den Treiber, der sich um den Rest kümmert.
Im Real Mode geht das mit der Hardware ja ganz einfach über Interrupts, wie funktioniert das im Protected Mode, bzw. was machen dann die Treiber?

Und kann man auch ohne Treiber/API-Funktionen Hardware (im Protected Mode) ansprechen?

dot

http://msdn.microsoft.com/en-us/library/windows/hardware/ff554678.aspx

Mechanics

Das geht auch über Interrupts, unter Linux werden Systemaufrufe über int 0x80 aufgerufen. Unter Windows so ähnlich sysenter.
Du "darfst" Hardware nicht ansprechen, weil normale Anwendungssoftware im Ring 3 läuft. Ein Treiber läuft im Ring 0, deswegen darf er das. Also wirds ohne Treiber nicht gehen.

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

Hallo,

wie kommunizieren Programme mit Treibern?

Ich meine, wenn Programme (z. B. Browser) auf das Internet zugreifen, dann nutzen sie wahrscheinlich einfach die von der System-API bereitgestellten Funktionen (Sockets usw.).

Was machen diese Funktionen genau, bzw. wie arbeiten sie?
Ist es möglich, auch ohne diese APIs direkt mit einem Treiber zu kommunizieren?

ich erklär das jetzt mal für Linux:
Die Treiber werden dort über Dateien im Dateisystem dargestellt (die haben natürlich keine Repräsentation auf der Festplatte).
Damit ist es möglich, dass du mit den üblichen Befehlen, die du vom Dateisystem her kennst, arbeiten kannst: open, read, write, close.
Beispielsweise wird die erste Festplatte im System als Datei /dev/sda dargestellt.

Du kannst dir z.B. den Bootsektor mit hexdump -n 512 /dev/sda anzeigen lassen, der Treiber für Festplatten nimmt deine Anforderung entgegen und erledigt die Arbeit für dich, sprich, liest die ersten 512byte von der Platte.
Während dieses hexdump Programm intern nur ein open, read und close macht, wird im Hintergrund des Block-Device-Treiber angeworfen, der sich darum kümmert, dass tatsächlich von der Festplatte gelesen wird.

Gut, soweit also die Treiber.

Dann gibts noch die sogenannten System calls, also vom OS zur Verfügung gestellte "Funktionen" (wie eben die von dir genannten sockets, aber auch trivialere Dinge wie open, close, ...). Ich setze das unter Anführungszeichen, weil es kein Funktionsaufruf im Sinne einer C Funktion ist.
Stattdessen werden die Daten, die du übergibst, in die CPU Register kopiert. Register EAX beinhaltet die Nummer der "Funktion", wenn du die den system call "open" (siehe oben, den brauchst du auch um auf die Treiber zugreifen zu können) aufrufen möchtest, befüllst du EAX mit dem Wert 5.
Die anderen Register werden benutzt, um die Daten zu übergeben, bsp. kommt in Register EBX die Adresse des Strings der den Dateipfad enthält.
Gut, alle Daten liegen jetzt in EAX, EBX, ECX, ...
Jetzt zum Aufruf: du löst einen Interrupt aus mit dem Befehl int 0x80. Die CPU pausiert den normalen Programmablauf, schaut in der Interrupt Tabelle nach (das ist einfach gesagt eine Liste von Funktionszeigern), welche Funktion sich um Interrupt Nummer 0x80 kümmert, und ruft diese Funktion aus. Die Funktion wird vom OS zur Verfügung gestellt. Sie liest dann gleich mal EAX aus und schaut nach, was zu tun ist. In unserem Fall ist EAX==5, also muss die Funktion sys_open ausgeführt werden. Wir befinden uns jetzt aber im Betriebsystemcode ("kernel mode"), der mit mehr Rechten ausgeführt wird als normaler User Code ("user mode").
Und so gibt es nicht nur open, sondern z.B. auch einen Systemcall für deine erwähnten Sockets: EAX muss 102 sein, damit wird dann die Funktion sys_socketcall aufgerufen.

achso, natürlich gibts für die system calls Wrapper Funktionen, sodass du in deinem C Programm nicht immer irgendwelche unschönen Inline Assembler Codestücke brauchst.

Wenn du also in deinem C Programm schreibst

void foo(int x)
{
 //...
 if(x==0)
   exit(0);
 //...
}

so macht das exit(0) folgendes:
setzt EAX auf 1, damit weiß dass OS dass es sys_exit aufrufen soll
setzt EBX auf den von dir gewünschten Wert, in dem Fall also 0
löst ein int 0x80 aus um die Kontrolle ans OS zu übergeben

also so in der Art (Pseudoassembler)

mov eax,1
mov ebx,argument
int 0x80

hustbaer

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

Ok, aber das scheint auch mit der Windows API zusammenzuhängen, aber ich wollte ja eben, dass keine API benutzt wird.

Die diversen Windows DLLs sind die einzige definierte Schnittstelle zum Treiber => ohne API geht es nicht.

Im Real Mode geht das mit der Hardware ja ganz einfach über Interrupts, wie funktioniert das im Protected Mode, bzw. was machen dann die Treiber?

Im Protected Mode geht es genau so über Interrupts, diesbezüglich ist nicht viel anders. Natürlich muss man auf viele Dinge acht geben bzw. sie über die Hilfsfunktionen des OS machen statt direkt auf die Hardware zuzugreifen, aber grundlegenden Unterschied gibt's jetzt nicht.

Und kann man auch ohne Treiber/API-Funktionen Hardware (im Protected Mode) ansprechen?

Klar, wenn das OS es erlaubt.
Die meisten erlauben es halt nicht.

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?

dot

------------------------- 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.

Bashar

------------------------- 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.

dot

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.

dot

------------------------- 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?

Bashar

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

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

Bashar

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?

dot

------------------------- 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...