Wie kommunizieren Programme mit Treibern?

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

SeppJ schrieb:

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

Ich sprach von Festplatten, leider ist mein Post auf der anderen Seite, weshalb du ihn vielleicht nicht gelesen hast:

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

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 hätte gerne einen Link zu so einem Standart.

hustbaer

Es gibt solche Standards, allerdings implementieren diese natürlich nicht *alle* Geräte.

Die meisten SATA Controller implementieren z.B. AHCI.
SAS oder SCSI Controller allerdings nicht.

Die Festplatten selbst entsprechen allerdings immer irgend einem Standard. IDE, ATAPI, SATA, SCSI, SAS - irgendsowas.

Wie kann ich erkennen, ob meine Festplatte AHCI unterstützt?

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

Wie kann ich erkennen, ob meine Festplatte AHCI unterstützt?

wie wärs wenn du dir ein buch zu dem thema besorgst z.b. das buch von prof. tanenbaum?
du wirst kaum in einem forum lernen können, wie ein OS funktioniert.
und deinen fragen nach zu urteilen fehlen dir einfach die basics.

hustbaer

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

Wie kann ich erkennen, ob meine Festplatte AHCI unterstützt?

Einfach: sie tut es nicht.
Dein SATA Controller aber vermutlich.