Wie arbeitet überhaupt ein Treiber? Und wie ist dieser programmiert?
> Wie arbeitet überhaupt ein Treiber? Und wie ist dieser programmiert? Allgemein? Unter Windows? Unter Linux? Unter Mac? Falls Du konkret Windows-Treiber und deren Programmierung meinst: http://www.codeproject.com/KB/system/driverdev.aspx http://www.codeproject.com/KB/system/driverdev2.aspx http://www.codeproject.com/KB/system/driverdev3.aspx ... An diesen Artikeln siehst Du die Komplexität Deiner Frage.
Konkret meine ich z.B. diesen Ausschnitt: "Dazu nutzt es Schnittstellen zum Kommunikationsbus oder anderen Kommunikationssystemen, an denen das Gerät angeschlossen ist, um Steuersignale und/oder Daten zum Gerät zu senden bzw. von ihm zu empfangen. Auf der anderen Seite stellt es eine Schnittstelle für eine Nutzung dieser Funktionen durch das Betriebssystem oder Anwendungsprogramme bereit."
Also prinzipiell ein Programm (mit Assembler geschrieben?!), das mit der angeschlossenen Hardware kommuniziert. Und jeder Zugriff auf die Hardware ist gleichzeitig auch ein Aufruf einer Treiberroutine? Passt das so? Jetzt frage ich mich allerdings, wie ein Treiber mit der Hardware kommuniziert. Ich meine, wenn ich eine Datei anlege, dann müsste der Festplattentreiber doch eine Routine dafür haben oder? Wie macht das ein Treiber? Wie wird zB eine Datei auf die Festplatte geschrieben. Hmmm
Lars schrieb: > ...? Wie wird zB eine Datei auf die Festplatte geschrieben. Hmmm Letzlich mit Befehlen der Art: gehe zu Zylinder xxx. schreibe beiliegende 512 Bytes in Sektor yy auf Seite y. oder bei linearer Adressierung schreibe 512 Bytes in Block zzzz, dann kümmert sich die Festplatte um Zylinder, Seite und Sektor. Um das Dateisystem, also DIR-Eintrag, Ordnerstruktur usw., kümmert sich ein Dateisystemtreiber (FAT, NTFS, CD), der dem physikalischen Treiber übergeordnet ist. Andere Geräte wie z.B. Messwertkarten werden über Bus und Adresse angesprochen, z.B. PCI Bus 0 Gerät 5. Gruss Reinhard
> mit Assembler geschrieben?! Kann sein, muss aber nicht. C ist auch ganz üblich. Im Prinzip geht fast jede Programmiersprache. Skriptsprachen werden aber eher selten dazu verwendet ;-) > das mit der angeschlossenen Hardware kommuniziert. Genau. Und das Betriebssystem ist meistens auch noch beteiligt (weil es ja bei normalen Anwendungen verhindert, dass diese direkt mit der Hardware kommunizieren können). Die meiste Hardware ist über irgendwelche standardisierte Busse (PCI, USB, ...) angeschlossen. Und das Betriebssystem bietet Schnittstellen an, mit deren Hilfe man was über diese Busse senden/empfangen kann. Ich glaube, das gilt auch für Festplatten. Ich glaube, die hängen auch irgendwie an einer PCI-Bridge oder so was. Diese vom Betriebssystem angebotene Schnittstelle muss jetzt natürlich auch irgendwie funktionieren. Es gibt da viele Wege: - DMA: Speicherbereiche, auf die die Hardware zugreifen kann. - Spezielle, virtuelle, Speicheradressen, die garnicht zum normalen RAM gehören sondern wo schreib-/lesebefehle vom Prozessor (oder Speicherbus) direkt an die Hardware geschickt werden. - Spezielle Befehle im Befehlssatz des Prozessors > Und jeder Zugriff auf die Hardware ist gleichzeitig auch ein Aufruf einer Treiberroutine? Zugriff von wem? - Vom Treiber: Kann natürlich auch intern wieder in Routinen aufgeteilt sein und diese dann aufrufen. - Vom Betriebssystem: Ja, genau. Das Betriebssystem ruft eine Treiberroutine auf. - Von der Anwendung: Ja, aber meistens nur indirekt über das Betriebssystem (Anwendung ruft Betriebssystemroutine und die ruft eine Treiberroutine auf). Was ist eigentlich die Motivation für deine Frage? Willst du einen Treiber schreiben (Vorsicht - ist nicht ganz einfach!)? Dann schau die Doku zum Betriebssystem und zur Hardware an. Oder nur aus Interesse? Dann hoffe ich, meine Antwort hat weitergeholfen (und hat nicht zu viele Fehler).
> Ich glaube, das gilt auch für Festplatten. Ich glaube, die hängen auch irgendwie an einer PCI-Bridge oder so was. Ich hatte anscheinend nur fast recht: IDE ja, SATA nein: http://de.wikipedia.org/w/index.php?title=Datei:Typical_intel_chipset.jpg&filetimestamp=20071122185556
sebastians schrieb: > Ich hatte anscheinend nur fast recht: IDE ja, SATA nein: Hallo, sowas ist nicht verpflichtend, genausogut kannst du die IDE an die Northbridge hängen oder Sata direkt an den Frontsidebus, du musst nur den Treiber entsprechend programmieren. Dafür hat man ihn ja. Gruss Reinhard
Danke für die Antworten. Ja, also die Motivation ist folgende: ich möchte verstehen, wie ein Betriebssystem mit der Hardware kommuniziert. Dafür braucht es ja Treiber, die extra dafür programmiert sind. Also findet die gesamte Kommunikation mit der Hardware über den Systembus statt, über bestimmte Speicheradressen? Was anderes kann eine CPU ja nicht, außer etwas in den Speicher zu schreiben. Das ist für mich so unverständlich irgendwie.
Lars schrieb: > Also findet die gesamte Kommunikation mit der Hardware über den > Systembus statt, über bestimmte Speicheradressen? Im Prinzip ja, beim X86 sind das zwar I/O-Adressen, aber die sind auch nichts anderes als Speicheradressen für einen speziellen Bereich. Die serielle Schnittstelle COM1 belegte in der ursprünglichen Version die I/O-Adressen 3F8 bis 3FF. 3F8 war für die Daten da, wenn man da ein Zeichen A reinschrieb, wurde es über die serielle Leitung gesendet. Gruss Reinhard
Ob ein Treiber nun per memory-mapped io oder auf einer CPU mit speziellen I/O-Befehlen die Hardware anspricht ist nebensächlich. Vielmehr ist es gerade die Aufgabe eines Treibers von der konkreten Ansteuerung zu abstrahieren. Ein sehr guter Tip zum lesen ist Andrew Tanenbaums Buch über Betriebssysteme. Dort sind solche Sachen detailliert erklärt.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.