Device File System Anleitung
Traditionelle Linux Distributionen bieten ihren Benutzern einen abstrakten Pfad zu den Geräten. Das ist /dev. In diesem Verzeichnis findet der Benutzer sogenannte Device Nodes. Das sind spezielle Dateien, die das entsprechende Gerät repräsentieren. Zum Beispiel repräsentiert /dev/hda das erste IDE Gerät im System. Durch das Bereitstellen von Gerätedateien kann der Benutzer Programme erstellen, die mit der Hardware wie mit einer regulären Datei interagieren, anstatt spezielle APIs zu benutzen. Die Gerätedateien sind in 2 Gruppen unterteilt. Die erste Gruppe, Character Devices genannt, besteht aus Hardware, deren Schreib- und Lesevorgänge nicht gepuffert sind. Die zweite Gruppe nennt sich Block Devices und enthält natürlich die Hardware, deren Schreib- und Lesevorgänge gepuffert sind. Beide Gerätearten können zeichenweise oder in Blöcken ausgelesen werden. Die Namensgebung kann deswegen verwirrend klingen und ist in der Tat falsch. Wenn Sie einen Blick auf eine Gerätedatei werfen, werden Sie etwas ähnliches wie das hier finden:
In dem vorangehenden Beispiel sehen wir, dass /dev/hda ein Block Device ist. Wichtiger sind jedoch die Zahlen, die ihm zugewiesen sind: 3, 0. Dieses Paar wird Major-Minor Paar genannt. Es wird vom Kernel dazu verwendet eine Gerätedatei dem echten Gerät zuzuweisen. Die erste Zahl verweißt auf ein bestimtes Gerät, die Zweite verweißt auf ein dem Ersten untergeordnetes Gerät. Das ist verwirrend? Ist es nicht. Hier zwei Beispiele: /dev/hda4 und /dev/tty5. Die erste Gerätedatei verweißt auf die vierte Partition des ersten IDE Geräts. Ihr Major-Minor Paar ist 3, 4. Mit anderen Worten, die erste Zahl verweißt auf das Gerät und die zweite auf die entsprechende Partition. Die zweite Gerätedatei hat 4, 5 als Major-Minor Paar. In diesem Fall verweist die erste Zahl auf den Terminal Treiber und die Zweite auf die Terminal Nummer (hier das fünfte Terminal). Wenn Sie in solch einem /dev Verzeichnis einen schnellen Check machen werden Sie bemerken, dass nicht nur alle ihre Geräte, sondern alle möglichen denkbaren Geräte aufgeführt sind. Mit anderen Worten, Sie haben Gerätedateien für Geräte die Sie nicht haben. Solch eine Gruppe von Gerätedateien zu pflegen ist, gelinde gesagt, lästig. Stellen Sie sich vor, Sie müssen die Berechtigungen aller Gerätedateien ändern, welche auf ein Gerät in ihrem System verweisen, aber den Rest der Gerätedateien lassen wie er ist. Wenn Sie neue Hardware in ihr System integrieren und diese vorher noch keine Gerätedatei hatte, werden Sie eine erstellen müssen. Erfahrene Benutzer wissen, dass diese Aufgabe mit ./MAKEDEV im /dev Verzeichnis erledigt werden kann. Aber wissen Sie sofort welche Gerätedatei Sie erstellen müssen? Wenn Sie Programme laufen haben die Hardware benutzen die Gerätedateien verwendet, können Sie ihre Root Partition nicht ohne Schreibzugriff mounten. Selbst wenn es keinen anderen Grund gibt sie mit Schreibzugriff gemountet zu haben. Sie können /dev nicht auf einer separaten Partition haben, weil mount /dev benötigt, um Partitionen zu mounten. Wie Sie sich sicher vorstellen können, haben die Kernel Hacker mehrere Wege gefunden die vorher genannten Probleme zu lösen. Jedoch hatten viele von ihnen andere Lösungen, die in diesem Dokument beschrieben sind. Wir werden diese Implementierungen nicht beachten, sondern uns auf die Eine konzentrieren, die es in die offiziellen Kernel Sourcen geschafft hat: devfs. devfs als Sieger in allen Klassen? devfs bewältigt alle angeführten Probleme. Es stellt dem Benutzer nur vorhandene Geräte zur Verfügung, erstellt neue Gerätedateien wenn neue Geräte gefunden werden und ermöglicht es, die Root Partition ohne Schreibzugriff zu mounten. Zusätzlich beseitigt devfs noch mehr Probleme, die vorher nicht berücksichtigt wurden, weil sie für den Benutzer weniger interessant sind... Zum Beispiel müssen Sie sich mit devfs keine Gedanken über Major-Minor Paare machen. Major-Minor Paare werden noch unterstützt (der Abwärtskompatibilität halber), aber sie werden nicht mehr gebraucht. Dies ermöglicht es Linux noch mehr Geräte zu unterstützen, seitdem es keine Grenzen mehr gibt (Zahlen haben immer Grenzen :)). devfs kommt mit seinen eigenen Problemen, für den Anwender sind diese Probleme nicht wirklich sichtbar, aber für Kernel Maintainer sind diese Probleme groß genug, um devfs als obsolet zu kennzeichnen.udev ist der Nachfolger, welcher von Gentoo unterstützt wird und seit der Version 2005.0 der Standard auf den meisten Architekturen ist, wenn ein 2.6 Kernel verwendet wird. Für weitere Informationen, warum devfs überholt gekennzeichnet ist lesen Sie bitte die udev FAQ und das udev versus devfs Dokument. 2. Navigieren in der /dev/ Verzeichnisstruktur Als erstes werden Sie bemerken, dass devfs Verzeichnisse benutzt um die Geräte zu gruppieren. Diese Vorgehensweise verbessert die Lesbarkeit, weil sich alle verwandten Geräte in einem Unterverzeichnis befinden. Zum Beispiel befinden sich alle IDE Geräte im Unterverzeichnis /dev/ide/ und alle SCSI Geräte in /dev/scsi/. SCSI und IDE Festplatten werden gleich behandelt, d. h. sie haben die selbe Verzeichnisstruktur im jeweiligen Unterverzeichnis. IDE und SCSI sind an einem IDE/SCSI Controller (Onboard oder eine extra PCI Karte) angeschlossen, den man host nennt. Jeder Controller kann mehrere Kanäle haben, die Bus gennant werden. In jedem Kanal können Sie mehrere IDs haben. Die ID, welche Target gennant wird, kennzeichnet eine Festplatte. Manche SCSI Geräte haben mehrere luns (Logical Unit Numbers). Zum Beispiel Geräte wie Hi-End Streamer, die mehrere Bänder auf einmal verwalten. Meistens gibt es aber nur eine lun, nämlich lun0/. Wo wir vorher /dev/hda4 benutzt haben, haben wir nun /dev/ide/host0/bus0/target0/lun0/part4. Das ist viel einfacher... Nein, streiten Sie nicht mit mir... es ist einfacher... ach, wie auch immer! :)
Um Ihnen eine Vorstellung zu verschaffen, hier die Liste der Verzeichnisse in /dev/ auf meinem Laptop:
Abwärtskompatibilität bei der Verwendung von devfs Mit diesem Schema zu arbeiten klingt gut, aber einige Programme nutzen das alte Schema. Um sicherzustellen, das alles im System intakt bleibt, wurde devfsd geschrieben. Dieser Daemon erstellt Symlinks mit den alten Namen, die auf die neuen Gerätedateien zeigen.
Mit devfsd können Sie auch Berechtigungen setzen, neue Gerätedateien erstellen, Aktionen definieren, usw. Das alles wird im nächsten Kapitel erklärt. Wenn Sie etwas in /etc/devfsd.conf ändern und wollen, dass Ihre Änderungen auf das System übertragen werden, müssen Sie nicht neustarten. Je nachdem was Sie wollen, können Sie eines der folgenden Signale nutzen: SIGHUP bringt den devfsd dazu, die Konfigurationsdatei neu zu lesen, die mehrfach genutzten Objektdateien neu zu laden und die Aktionen zum Registrieren der Gerätedateien auszuführen. SIGUSR1 bewirkt das Gleiche, aber es werden keine Registrierungen vorgenommen. Um solch ein Signal zu senden, benutzen Sie kill oder killall:
Symlinks für die Abwärtskompatibilität entfernen
Wenn Sie die Symlinks, die /dev/ vollstopfen, aus ihrem Gentoo System entfernen wollen (sie sind standardmäßig aktiviert), editieren Sie /etc/devfsd.conf und entfernen Sie die folgenden zwei Zeilen:
Um diese Änderungen zu übernehmen, müssen Sie ihr System neustarten. Deaktivieren der Autoload Funktionalität Wenn Sie ein Modul laden erstellt devfs automatisch die zugehörigen Gerätedateien. Wenn Sie das nicht wollen, entfernen sie die folgende Zeile aus ihrer /etc/devfsd.conf:
Setzen/Ändern von Berechtigungen mit devfsd
Wenn Sie die Berechtigungen mittels /etc/devfsd.conf setzen wollen, nutzen Sie bitte die Syntax aus dem folgendem Beispiel:
Im zweiten Feld wird die Gerätegruppe angegeben, beginnend in /dev. Hier werden reguläre Ausdrücke verwendet, Sie können also mehrere Gerätedateien auf einmal auswählen. Im vierten Feld wird der Owner (mit Gruppe) angegeben und das fünfte Feld enthält die Berechtigungen für die Gerätedatei. Berechtigungen von Hand setzen und mit devfsd speichern Hier die normale Vorgehensweise bei Gentoo-Installationen: Wenn Sie mit chown (CHangeOWNer) und chmod (CHange MODe) einige Gerätedateien verändern, speichert devfsd die Informationen damit diese über das Neustarten hinweg erhalten bleiben. Das passiert weil /etc/devfsd.conf folgendes enthält:
Genauer erklärt, geänderte Gerätedateien werden sowie die Änderung erfolgt nach /lib/dev-state kopiert und beim Hochfahren wieder nach /dev zurückkopiert. Eine andere Möglichkeit besteht darin während des Bootvorgangs /lib/dev-state nach /dev zu mounten. Allerdings müssen Sie sicherstellen, dass devfs nicht automatisch beim Starten gemountet wird (Sie müssen dazu ihren Kernel neu kompilieren) und das /dev/console existiert. Dann platzieren Sie irgendwo am Anfang ihrer Startskripte folgendes:
Für mehr Informationen über devfs, hier noch ein paar Quellen: Die devfsd.conf Manpage erläutert die Syntax von /etc/devfsd.conf. Um sie anzusehen führen Sie man devfsd.conf aus. Die devfs FAQ erklärt alles rund um devfs. Sie enthält auch Informationen über die interne devfs Struktur und wie Treiber devfs unterstützen können. Im LinuxJournal ist ein informativer Artikel über devfs zum Managen und Administrieren. Daniel Robbins schrieb einige Artikel für IBMs DeveloperWorks über erweiterte Dateisysteme. Drei behandeln devfs: Die Inhalte dieses Dokuments sind, sofern nicht explizit anders genannt, unter der Creative Commons - Namensnennung / Weitergabe Lizenz lizenziert. Die Gentoo Name and Logo Usage Guidelines treffen zu. |
|