Wie kommunizieren Programme mit Treibern?

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.

Bashar

dot schrieb:

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

Microsoft hat einen Wettbewerbsvorteil, wenn es keine Treiber für freie Betriebssysteme gibt, daher gibt es da auch den einen oder anderen Deal, über den die Öffentlichkeit nichts oder erst sehr viel später etwas erfährt (Knebelverträge.) Zumindest war das früher der Fall, als Microsoft noch Relevanz hatte.

Also soweit ich weiß, gibt es auch Hardware-Hersteller, die auch Treiber für Linux entwickeln. Die Treiber sind nur nicht open-source...
(Nvidia?)

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

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

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

zu hardware gibts eigentlich immer irgendwelche datasheets.
das sieht dann z.b. so aus: http://www.cs.usfca.edu/~cruse/cs326/RTL8139D_DataSheet.pdf

manchmal meinen hersteller, spezifikationen geheimhalten zu müssen.
siehe das thema DVD mit all ihren tollen features wie ländercodes usw...
früher oder später wird das aber ohnehin geknackt, und sei es auch nur, wie bei der DVD, weil anwender ihre DVDs auf Linux abspielen wollten und nicht nur auf Win98.

hustbaer

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

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?

Nicht nur andere Ports, die Unterschiede sind z.T. massiv.
Was glaubst du warum du beim Installieren von Windows bereits während des Setup nen Treiber mit [F8] laden musst, wenn dein PC z.B. nen SCSI Controller hat (und die Disk auf die du installierst über diesen angesprochen wird)?

Nächste Frage:

Sind diese Ports, bzw. die Befehlsreferenz von Festplatten genormt?

Also kann jede Festplatte über Port x angesprochen werden, und mit Byte z kann ich b Bytes von Offset o in den RAM laden?

... ich meine nur, dass es viel Sinn machen würde, dass es wenigstens herstellerunabhängige Spezifikationen gibt, die die Hersteller implementieren, zumindest für Festplatten... ?

dot

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

... ich meine nur, dass es viel Sinn machen würde, dass es wenigstens herstellerunabhängige Spezifikationen gibt, die die Hersteller implementieren, zumindest für Festplatten... ?

In der Tat, für viele Arten von Geräten gibt es sowas...

... Link?

SeppJ

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

... Link?

Für was? Alle Arten von Hardwarestandards, die es jemals gegeben hat? Kannst du sogar haben:
http://en.wikipedia.org/wiki/Category:Computer_hardware_standards