Linux Hardware Hacks

von: Jürgen Plate

Carl Hanser Fachbuchverlag, 2007

ISBN: 9783446413627 , 467 Seiten

Format: PDF, OL

Kopierschutz: Wasserzeichen

Windows PC,Mac OSX für alle DRM-fähigen eReader Apple iPad, Android Tablet PC's Online-Lesen für: Windows PC,Mac OSX,Linux

Preis: 31,99 EUR

Mehr zum Inhalt

Linux Hardware Hacks


 

3 E/A-Programmierung

Wie schon im ersten Kapitel angedroht, geht es nun um das Ansprechen von Hardware per Programm. Dort wurde auch schon gesagt, dass es zwei Möglichkeiten gibt, E/E-Schnittstellen anzusprechen: Treiber oder direkter Portzugriff, der unter dem Begriff User-Mode-Programm läuft.

Kernel-Treiber sind, wie der Name schon sagt, Bestandteil des Kernels. Sobald sie eingebunden sind, können sie von allen Programmen gleichermaßen und ohne besondere Privilegien genutzt werden. Sie werden aus anderen Programmen angesprochen über

Einträge im /dev-Verzeichnis,
das /proc-Verzeichnis oder
ioctl()-Aufrufe.

Damit folgen die Treiber auch dem UNIX/Linux-Grundsatz " Alles ist Datei". Dieser Vorteil wird durch eine komplexere Programmierung erkauft. So ist z. B. der Zugriff auf Bibliotheksfunktionen eingeschränkt. Die Alternative besteht in User-Mode-Programmen, die direkt auf E/A-Ports zugreifen und damit auch immer nur mit Root-Privilegien starten müssen (nach erfolgreicher Missetat kann man auf normale User-Privilegien umschalten). Verwendet man dagegen ein User-Mode-Programm für Hardwarezugriffe, gilt:

die C Library kann benutzt werden,
Debugging ist einfacher und
Paging ist möglich.

Die Programmierung ist somit viel einfacher. Aber es gibt auch Nachteile gegen über einem Treiber:

Interrupts lassen sich nicht verwenden,
Performance ist nicht so gut wie bei Kernel-Treibern,
Verzögerungen entstehen durch den Scheduler und
Root-Rechte sind für den Zugriff erforderlich.

Bei Embedded Systems, wo nur wenige Prozesse laufen und ein User-Login meist gar nicht möglich ist,überwiegt oft der Vorteil der einfachen Programmierung. Der Abschnittüber Treiber und auch die entsprechenden Abschnitte in anderen Kapiteln müssen zwangsläufig rudimentär sein, sonst wäre dieses Buch mindestens 500 Seiten dicker geworden. Alle, die mehr wissen wollen, seien auf das Buch von Quade und Kunst bzw. dessenWebseite http://ezs.kr.hsnr.de/TreiberBuch/ verwiesen. Deshalb wird nach einem kurzen Ausflug zum Compiler zuerst die User-Mode- Programmierung behandelt, anschließend gibt es einen kleinen Ausflug in die Treiberentwicklung.

3.1 Compiler und Bibliotheken

Wenn Sie mit gängigen Distributionen arbeiten, installieren Sie zumeist nur fertig kompilierte Programme (sogenannte Binärpakete). Für unsere Anwendungen müssen Sie in der Regel den Quellcode herunterladen oder selbst verfassen und dann das Programm selbst kompilieren. Deshalb gebe ich Ihnen dazu einige einführende Tipps.

Praktisch alle Linux-Programme verwenden dieselben Standardfunktionen, beispielsweise zum Zugriff auf Dateien, zur Ausgabe am Bildschirm, zur Unterst ützung von X etc. Es wäre sinnlos, wenn jedes noch so kleine Programm all diese Funktionen unmittelbar imCode enthaltenwürde – riesige Programmdateien wären die Folge. Stattdessen bauen die meisten Linux-Programme auf sogenannten shared libraries auf: Bei der Ausführung eines Programms werden automatisch auch die erforderlichen Libraries (Bibliotheken) geladen. Der Vorteil:Wenn mehrere Programme Funktionen derselben Library nutzen, muss diese nur einmal geladen werden.

Bibliotheken spielen eine zentrale Rolle dabei, ob und welche Programme auf Ihrem Rechner ausgeführt werden können. Fehlt auch nur eine einzige Bibliothek (bzw. steht sie in einer zu alten Version zur Verfügung), kommt es beim Programmstart sofort zu einer Fehlermeldung.

Kompilierte Programme können nur dann ausgeführt werden, wenn die dazu passenden Bibliotheken installiert sind und auch gefunden werden. Mit dem Kommando ldd kann man feststellen, welche Bibliotheken von einem Programm benötigt werden. ldd wird als Parameter der vollständige Dateiname des Programms übergeben. Als Reaktion listet ldd alle Libraries auf, die das Programm benötigt. Außerdem wird angegeben, wo sich eine passende Library befindet und welche Libraries fehlen bzw. nur in einer veralteten Version zur Verfügung stehen. Wenn ldd das Ergebnis not a dynamic executable liefert, handelt es sich um ein Programm, das alle erforderlichen Bibliotheken bereits enthält (ein statisch gelinktes Programm).