Gerätedatei

Unter UNIX wird jegliche verfügbare Hardware, die dem System zur Verfügung steht, durch eine Datei, bzw. durch mehrere Dateien in einem Unterverzeichnis (standardmäßig) im Verzeichnis „/dev“ repräsentiert, so auch unter Linux.

Dieser Artikel bietet einen kurzen Überblick über die Verschiedenen Arten von Gerätedateien, nennt zudem einige Beispiele für die jeweilige Art der Gerätedateien und zeigt Beispiele für deren Verwendung auf.

Überblick

Durch Gerätedateien wird eine einfach verfügbare Schnittstelle zwischen dem Anwender und seinen Programmen, und dem Betriebssystem-Kernel geschaffen. Durch den Zugriff auf drei (vier) unterschiedliche Typen von Gerätedateien (siehe weiter unten) hat man praktisch direkten Zugriff auf die jeweilige Hardware.

Allen Gerätedateien gleich ist, dass deren Verwendung vollkommen Transparent ist. Um etwas auf einem Drucker auszudrucken, der über eine parallele Schnittstelle an den Computer angeschlossen ist, reicht es zum Beispiel, den Text direkt in die Gerätedatei des Druckers zu schreiben (mit Netzwerkdruckern funktioniert dies freilich nicht ohne weiteres). Es bedarf keines speziellen Programms, um mit Gerätedateien arbeiten zu können.

Gerätedateien werden vom System in „/dev“ verwaltet. Dies geschieht heutzutage mittels udev. Dieses wurde mit Veröffentlichung des 2.6-Kernels als Standard-System für Gerätedateien eingeführt. Anders als sein Vorgänger devfs ist udev Plug-And-Play-fähig (Hotplugging) und benötigt kein spezielles Dateisystem mehr für die Verwaltung der Gerätedateien.

Beispiele

Die nachfolgenden Beispiele zeigen die wichtigsten und bekanntesten Gerätedateien eines jeweiligen Typs auf. Sofern nicht anders angegeben, beziehen sich die Namen auf Dateien oder Verzeichnisse unterhalb von „/dev“.

Zeichenorientiert

Beim Zugriff auf zeichenorientierte Geräte („character devices“) wird die Information immer zeichenweise übertragen. Dabei wird immer ein Zeichen zu einem Zeitpunkt übertragen. Zeichenorientierte Geräte haben die Kennung „character special“, wenn man sie mittels „file“ untersucht.

• ttyN repräsentiert das Pseudoterminal mit der Nummer N.
• input/mice – Diese Gerätedatei ist eine „Sammeldatei“ für alle angeschlossenen mausartigen Eingabegeräte
• lpN entspricht der parallelen Schnittstelle mit der Nummer N. Über diese Schnittstelle kann z.B. ein altes Modem oder ein Drucker angesprochen werden
• stdin, stdout und stderr werden unter Arch als Symlinks in „/dev“ repräsentiert, deren Ziele sind ebenfalls zeichenorientierte Gerätedateien.

Blockorientiert

Blockorientierte Geräte („block devices“) übertragen Daten – auch parallel – in einem Block, und nutzen den Systemeigenen Puffer. Blockorientierte Geräte werden von „file“ als „block special“ bezeichnet.

• hdX und hdXN repräsentieren per IDE angeschlossene Festplatten. X ist die Nummer der Platte, und N ist die Nummer der Partition
• sdX und sdXN repräsentieren die per SCSI/SATA angeschlossenen Festplatten. Es gilt hier die selbe Nummerierung wie bei den per IDE angeschlossenen Festplatten
• fdN ist die Gerätedatei des Diskettenlaufwerkes mit der Nummer N
• cdrom und dvd verweisen auf die tatsächliche Gerätedatei des CD/DVD-Laufwerkes

Socketorientiert

Socketorientierte Geräte („socket devices“) sind eigentlich keine Gerätedateien, sondern dienen zur Inter-Prozess-Kommunikation. Ein bekannteres Beispiel hierfür sind FIFO-Pipes. Allerdings befinden sich auch einige dieser Dateien in „/dev“.

• log ist eine Socket-Datei für den Syslog-Daemon

Weitere Dateien könnten zum beispiel gpmdata als Socket für den Multiplexer einer GPM-Maus oder printer als Socket für lpd sein. Socket-Dateien sind in „/dev“ allerdings sehr rar. „file“ benennt Socket-Dateien als „socket“.

Virutelle Geräte

Über virtuelle Geräte („virtual devices“) greift man nicht auf tatsächlich vorhandene Hardware zu, sondern steuert über sie Funktionen oder kann informationen auslesen. Virtuelle Geräte werden von „file“ als das erkannt, als das sie definiert wurden.

• null – Beim Zugriff auf „/dev/null“ wird sofort ein EOF zurückgegeben. Wenn man dorthin etwas ausgibt, „verschwindet es im Nirgendwo“, da dem ausgebenden Programm sofort ein abgeschlossenes Ausgeben signalisiert wird.
• random ist ein Zufallszahlengenerator, der zum Generieren der Zufallszahlen das Umgebungsrauschen von Gerätetreibern in einem Entropiepool speichert. Beim Zugriff auf diese Datei werden aus dem Entropiepool Zufallszahlen erzeugt, bis dieser leer ist, danach wartet das System auf neue Daten im Entropiepool
• urandom ist ebenfalls ein Zufallszahlengenerator. Allerdings blockiert dieser nicht, wenn die Entropie-Quelle erschöpft ist. Allerdings erzeugt „/dev/urandom“ nur Pseudozufallszahlen
• zero gibt beim Zugriff einen Zeichenstrom aus Null-Oktetts zurück. Das ergebnis des Zugriffs auf „/dev/zero“ ist also permanent 0, egal, wie lange der Zugriff dauert.

Verwendung

Nachfolgende Anwendungsfälle können Schaden am System verursachen und dienen ausschließlich der Dokumentation der Verwendung von Gerätedateien. Es wird nicht empfohlen, diese Dinge durchzuführen, wenn man sich nicht zu hundert Prozent sicher ist, was man tut.

Zeichenorientiert

Um etwas auszudrucken, kann man es direkt an die parallele Schnittstelle senden. Der dort angeschlossene Drucker druckt es dann aus.

echo "Dies wird ausgedruckt" > /dev/lp0

Dies funktioniert standardmäßig unter Arch nur mit root-Rechten. Ebenfalls nur mit root-Rechten funktioniert das Ausgeben von z.B. der Maus-Sammel-Gerätedatei „/dev/input/mice“.

cat /dev/input/mice

Wenn man nun die Maus bewegt, erscheinen Zeichen auf dem Bildschirm. Diese Zeichen repräsentieren das, was dem System beim bewegen der Maus übergeben wird. Da die Shell damit nichts anfangen kann, werden die den Signalen entsprechenden Zeichen ausgegeben.

Blockorientiert

Ausgabe des gesicherten MBRs mittels cat in xterm

Will man zum Beispiel vom Master-Boot-Record mittels dd ein Backup anfertigen, und weiß, dass die Informationen auf sda1 zu finden sind, bedient man sich folgenden Befehls.

dd if=/dev/sda of=/home/backups/mbr-sicherung bs=512 count=1

Dies sichert die ersten 512 Bytes von sda als „/home/backups/mbr-sicherung“. Wenn man sich diese Datei nun ansieht, wird man bis auf Zeichensalat nicht viel erkennen können. Wenn man dies allerdings mittels dd wieder zurückschreibt, kann man den MBR wieder herstellen, falls er durch ein anderes Programm zerstört worden sein sollte.

Socketorientiert

FIFO-Pipes werden als socketorientierte Gerätedateien bezeichnet. Wenn man eine FIFO-Pipe verwenden will, muss diese zuerst angelegt werden. Danach kann man sie zum beispiel als Ausgabeumleitungs-Ziel verwenden.

mkfifo fifopipe
ls -l / > fifopipe &
cat fifopipe

Diese (eigentlich unnütze und nur der Demonstration dienende) Verwendung der FIFO-Pipe macht folgendes: Zuerst wird die FIFO-Pipe angelegt, dann wird die Ausgabe von „ls -l /“ an diese FIFO-Pipe gesendet. Nun wird mittels „cat“ die Pipe ausgegeben. Man sieht nun die Ausgabe von „ls -l /“.

Netzwerkverbindungen werden zwar auch als Sockets verwendet, allerdings werden sie direkt über den TCP/IP-Stack des Systems angesprochen, und nicht über die Gerätedatei.

Virtuell

Will man eine Zufallszahl erzeugen, kann man sich „/dev/random“s bedienen.

dd if=/dev/random bs=100 count=1 2> /dev/null | md5sum

Hier wird mittels dd ein 100 Byte langer String aus „/dev/random“ geholt, die Statusausgabe von dd unterdrückt, so, dass nur das Ergebnis zurückgegeben wird, und von diesem Ergebnis dann mittels md5sum die MD5-Summe gebildet. Nun hat man eine Hexadezimale Zufallszahl, mit der man weiterarbeiten kann.

Ein weiteres Beispiel zeigt sich im obigen Aufruf ebenfalls. dd hat nur unzureichende Möglichkeiten, die Statistik-Informationen zu verbergen, sendet diese aber auf STDERR. Mittels einer Ausgabeumleitung wird alles, was dd auf STDERR ausgibt, nach „/dev/null“ geleitet, und somit „vernichtet“.

Siehe auch

• Wiki-Artikel zu Ein- und Ausgabeumleitungen in der bash

Weblinks

• Anleitung von HP zum Erstellen von Gerätedateien
• Bezug des Datesystembaum-Standards