Wie kommunizieren Programme mit Treibern?

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

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

Bashar

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

dot

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

dot

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

dot

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

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?

Ja? Schonmal überlegt, woher es wohl kommt, dass es unter Linux ständig diese Probleme von wegen Driver für gewisse Geräte gibt? Bestes Beispiel sind wohl Grafikkarten...

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

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

Sehr wahrscheinlich ist das der Grund...

Ist schon komisch, warum sollte man solche Spezifikationen zurückhalten?

Aber sonst danke für eure Antworten.

dot

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

Ist schon komisch, warum sollte man solche Spezifikationen zurückhalten?

Weil solche Spezifikationen sehr viel darüber verraten, wie genau die Hardware funktioniert und viele Firmen aus offensichtlichen Gründen wohl verhindern wollen, dass die Konkurrenz derlei Details über ihre Hardware erfährt!?

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

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?

nein, das BIOS ist nur beim Starten relevant, es kopiert die ersten 512byte vom Startmedium in den RAM und übergibt die Kontrolle dann dort hin.
Diese 512 byte sind der Bootloader, wie etwa GRUB. Und dieser Bootloader ladet dann das OS, bzw. bietet eine Auswahlliste an, wo man sich z.B. zwischen Linux und Windows entscheiden kann.

Die gesamte Kommunikation mit der Hardware geschieht dann über das OS bzw. über die in das OS geladenen Module (Treiber).
Genauso wie man auf den RAM über Adressen zugreifen kann und von dort lesen/schreiben kann, so gibt es auch den IO Bus. Über den kann man auf bestimmte Adressen zugreifen und von dort lesen/schreiben.
Nur dass dann eine bestimmte IO Adresse nicht mit einer RAM Speicherzelle zusammengehört, sondern ein Hardwareregister eines Geräts darstellt.
Beispielsweise gibt es im OS Code, der sich darum kümmert, den Hardware Timer entsprechend zu programmieren, sodass dieser regelmäßig einen Interrupt auslöst, wodurch das OS wiederum zeitrelevante Dinge wie Scheduling erledigen kann.
Die ASM Befehle dazu sind die in/out Befehle, dadurch kann man an eine bestimmte IO Adresse ein Byte schreiben/lesen.

Hier z.B. ein "Treiber" für den erwähnten Timer (PIT), der Code initialisiert den Timer indem an bestimmte IO Adressen == Register des PIT bestimmte Werte geschrieben werden:

void pit_init(int freq)
{
   int counter = 1193182 / freq;
   outb(0x43, 0x34);
   outb(0x40,counter & 0xFF);
   outb(0x40,counter >> 8);
}

sofern dich das Thema im Detail interessiert, hol die das Buch "Understanding the Linux Kernel", dann siehst du wie ein modernes OS unter der Haube funktioniert.

@gdfgdfgd:
danke, habe mittlerweile verstanden, wie das mit inb und outb geht.

Ich weiß aber garnicht, woher die Entwickler diese Spezifikationen herbekommen

Mechanics

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

Ich weiß aber garnicht, woher die Entwickler diese Spezifikationen herbekommen

Entweder dokumentieren die Entwickler der Hardware das, oder es gibt allgemeingültige Standards, oder man muss sich die Infos durch Reverse Engineering zusammensuchen. z.B. mit einem USB Sniffer schauen, was so an Daten übertragen wird, wenn ein offizieller Windows Treiber benutzt wird. Oder den Treiber disassemblieren usw.