SDB:Überblick über das SUSE Linux Hotplug System

aus openSUSE, der freien Wissensdatenbank


Version: 9.1 -

Inhaltsverzeichnis

Überblick über das SUSE Linux Hotplug System

Das SUSE Linux Hotplug System wurde vom Linux Hotplug Projekt abgeleitet, verhält sich aber etwas anders. Der Hauptunterschied besteht darin, dass zum Initialisieren/Stoppen der Geräte nicht der Event Multiplexer (/etc/hotplug.d/) benutzt wird, sondern /sbin/hw{up,down}. In diesem Dokument werden die Unterschiede zwischen den beiden Methoden sowie das vollständige SUSE Linux Hotplug System beschrieben.

Funktionsweise

Hotplug wird immer benutzt

Das Hotplug System wird nicht nur für Geräte benutzt, die zur Laufzeit angeschlossen oder entfernt werden können, sondern für alle Geräte, die entdeckt werden, nachdem der Kernel gestartet wurde. Das bedeutet, dass vor dem Start von Hot-/Coldplug nur grundlegende Geräte initialisiert werden: das Hauptbussystem (meistens PCI), Bootlaufwerke, Tastatur usw. Alle Hotplug-Geräte besitzen einen Eintrag im sysfs.

Geräte und Schnittstellen

Hotplug kümmert sich sowohl um Geräte (devices) als auch um Schnittstellen (interfaces). In diesem Dokument unterscheiden wir zwischen Geräten und den Schnittstellen zu Geräten. Ein Gerät ist derjenige Teil, der an irgendeinem Bus oder einer Schnittstelle angeschlossen wird. Eine Schnittstelle ist das, was von diesem Gerät zur Verfügung gestellt wird, um ein anderes Gerät oder eine Anwendung anzuschließen. In sysfs findet man die Geräte in /sys/devices. Schnittstellen werden in /sys/class oder /sys/block aufgelistet. Alle Schnittstellen sollten einen Verweis auf ihre Geräte in sysfs besitzen, jedoch gibt es immer noch Treiber, die keinen Verweis einfügen.
Beispiele:

  • Eine PCI-Netzwerkkarte ist ein Gerät, das am PCI Bus angeschlossen ist (/sys/devices/pci0000:00/0000:00:1e.0/0000:02:00.0). Dieses Gerät stellt eine Netzwerkschnittstelle bereit, die von Netzwerkdiensten benutzt wird oder an der virtuelle Netzwerkgeräte (zum Beispiel ein Tunnel oder VLAN) angeschlossen werden (/sys/class/net/eth0).
  • Ein PCI SCSI Controller ist ein Gerät (/sys/devices/pci0000:20/0000:20:01.1), das verschiedene physische Schnittstellen in Form eines Busses (/sys/class/scsi_host/host1) bereitstellt.
  • Eine SCSI-Festplatte ist ein Gerät (/sys/devices/pci0000:20/0000:20:01.1/host1/1:0:0:0) mit mehreren Schnittstellen (/sys/block/sda*)

Hotplug-Events

Alle anderen Geräte und Schnittstellen werden mittels Hotplug initialisiert. Für jedes Gerät oder jede Schnittstelle gibt es einen Hotplug-Event, der vom zugehörigen Hotplug-Agenten verarbeitet wird. Hotplug-Geräteevents werden auf zwei verschiedene Arten ausgelöst:

  • Vom Kernel, wenn die Verbindung zu einem Gerät hergestellt wird. Auch hier unterscheiden wir wieder zwei Fälle:
    + Der Bus oder die Schnittstelle, an die das Gerät angeschlossen wurde, ist bereits aktiv und das Gerät ist physisch angeschlossen (USB, PCMCIA, manchmal PCI, ...). Der Bustreiber erzeugt einen Event für jedes angeschlossene Gerät.
    + Das Gerät wurde bereits physisch angeschlossen, aber der darunterliegende Bus oder die Schnittstelle wurde noch nicht initialisiert. Wenn jetzt der Bus initialisiert wird, durchsucht der Bustreiber den Bus nach allen angeschlossenen Geräten und erzeugt für jedes Gerät einen Event.
  • Von Coldplug, welches wichtige Busse erneut durchsucht und für alle Geräte, die immer noch nicht initialisiert wurden, Events erzeugt.

Außerdem gibt es Schnittstellenevents, die vom Kernel ausgelöst werden, sobald ein Treiber eine Schnittstelle registriert.

Einen Hotplug-Event erzeugen bedeutet, dass ein Hotplug-Usermode-Tool aufgerufen wird, gewöhnlich ist dies /sbin/hotplug. Der Kernel ruft auf, was in /proc/sys/kernel/hotplug eingetragen wurde. Das Usermode-Tool /sbin/hotplug sucht einen Hotplug-Agenten, der zum Eventtyp passt. Falls es für diesen Eventtyp keinen Agenten gibt und im Gerätepfad eine Datei 'dev' existiert, ruft es generic_udev.agent auf.

Wenn bestimmte Eventtypen stets ignoriert werden sollen, so kann man sie in der Datei /etc/sysconfig/hotplug auf HOTPLUG_SKIP_EVENTS setzen.

Hotplug-Agenten

Seit der Kernelversion 2.6 gibt es so viele verschiedene Hotplug-Events, dass es schwierig ist, alle zu kennen. Jeder neue Treiber kann einen neuen Eventtyp einführen. Zu allen gut bekannten Events gibt es zugeordnete Agenten, die die nötigen Aktionen ausführen.

Geräteagenten laden hauptsächlich Kernelmodule, manchmal müssen jedoch einige zusätzliche Befehle aufgerufen werden. Bestimmte Hardware-Architekturen, z.B. IBM S390, erwarten zur Aktivierung eines jeden Gerätes, dass irgendwo in procfs oder sysfs spezielle Werte eingetragen werden. Das SUSE Linux Hotplug System ruft für solche Aufgaben immer /sbin/hw{up,down} auf. Es sucht im Verzeichnis /etc/sysconfig/hardware nach einer zum Gerät passenden Konfiguration und benutzt die dort gefundenen Informationen. Wenn hwup keine Konfiguration findet, greift es auf das automatische Laden von Modulen zurück. Siehe weiter unten "Automatisches Laden von Modulen". Einzelheiten zu hw{up,down} finden Sie in der Datei /usr/share/doc/packages/sysconfig/README und in 'man hwup'. In zukünftigen Versionen wird das automatische Laden von Modulen vollständig wegfallen, und falls keine Konfigurationsdatei gefunden wurde, wird hwup die Konfiguration anstoßen.

Schnittstellenagenten erfüllen hauptsächlich zwei Aufgaben: die Einrichtung einer Schnittstelle und/oder den Aufruf von udev zur Erzeugung eines Geräteknotens. Die Einrichtung der Schnittstellen wird von /sbin/if{up,down} übernommen, gegenwärtig jedoch nur für Netzwerkschnittstellen. Weitere Einzelheiten zu if{up,down} finden Sie in den Erklärungen zu sysconfig in /usr/share/doc/packages/sysconfig/README und in der Manpage zu ifup. udev verfügt ebenfalls über eine eigene Dokumentation und Manpage.

Falls es für einen bestimmten Event keinen Agenten gibt und im Gerätepfad in sysfs eine Datei 'dev' existiert, wird ein generischer udev-Agent aufgerufen, um sicherzustellen, dass alle benötigten Geräteknoten erzeugt werden.

Automatisches Laden von Modulen

Alle Agenten, die Geräte initialisieren müssen, versuchen ein Treibermodul für das Gerät zu finden, falls hwup fehlschlägt. Hierzu werden einige Modulmaps ausgewertet. Alle Agenten schauen zuerst in eine Datei /etc/hotplug/*.handmap und nur wenn dort nichts gefunden wurde, durchsuchen sie /lib/modules/<kernelversion>/modules.*map. Falls die Voreinstellung aus der Kernelmap Ihnen nicht zusagt, können Sie deshalb eine passende Zeile in die Datei *.handmap einfügen.

Wie so oft, gibt es für PCI und USB zwei zusätzliche Regeln:

  • USB: Das Skript usb.agent schaut auch in /etc/hotplug/usb.usermap und /etc/hotplug/usb/*.usermap nach Usermode-Treibern; das bedeutet, dass für bestimmte Geräte ausführbare Programme gestartet werden können.
  • PCI: Das Skript pci.agent fragt zuerst hwinfo nach Treibermodulen und schaut nur dann in die Map-Dateien, wenn hwinfo keinen Treiber liefert. Da hwinfo in die Dateien pci.handmap und in die Kernelmap schaut, sollte dies normalerweise nicht nötig sein. hwinfo besitzt eine zusätzliche Datenbank, die nach pci.handmap aber noch vor der Kernelmap ausgewertet wird.

Zusätzlich kann der pci.agent darauf beschränkt werden, nur Module aus bestimmten Unterverzeichnissen von /lib/modules/<kernelversion>/kernel/drivers zu laden. Wenn wenigstens ein Unterverzeichnisname in HOTPLUG_PCI_DRIVERTYPE_WHITELIST existiert, werden nur Module aus diesen Unterverzeichnissen geladen werden. Module aus Unterverzeichnissen, die in HOTPLUG_PCI_DRIVERTYPE_BLACKLIST aufgelistet sind, werden nie geladen.

Schließlich gibt es noch die Datei /etc/hotplug/blacklist. Diese Datei enthält eine zeilenweise Auflistung der Modulnamen, die von keinem Agenten geladen werden sollen.

Falls es in einer Map mehrere passende Module gibt, wird das Laden gestoppt, nachdem ein Modul erfolgreich geladen wurde. Normalerweise sind diese Extramodule lediglich alternative Treiber. Damit hotplug alle passenden Module lädt, muss HOTPLUG_LOAD_MULTIPLE_MODULES=yes gesetzt werden.

Beachten Sie, dass dies keinen Einfluss auf das Modulladen via hwup hat. Das automatische Laden von Modulen ist lediglich ein Fallback-Mechanismus, der bald nicht mehr zur Verfügung stehen wird.

Netzwerkgeräte und ihre Schnittstellennamen

Wenn es mehrere Netzwerkgeräte gibt, die verschiedene Treiber haben, so kann es geschehen, dass die Schnittstellennamen für diese Geräte nach jedem Booten zufällig wechseln. Das liegt daran, dass Hotplug-Events asynchron verarbeitet werden und zwei Treiber deshalb ihre Geräte parallel initialisieren. Das bedeutet, dass es zwischen diesen Prozessen zu einer Race-Condition kommen kann.

Um dieses Problem zu vermeiden, werden Events für Netzwerkgeräte in eine Warteschlange eingereiht. Falls das aus irgend einem Grunde problematisch sein sollte, kann man dieses Verhalten in /etc/sysconfig/hotplug mittels HOTPLUG_PCI_QUEUE_NIC_EVENTS=no abschalten.

Um persistente Schnittstellennamen zu erhalten, wird empfohlen, Schnittstellennamen innerhalb der Schnittstellenkonfigurationsdateien zu vergeben; dann ist die Verarbeitung der Events über eine Warteschlange nicht mehr länger nötig. Siehe den Abschnitt über persistente Namen in der Datei /usr/share/doc/packages/sysconfig/README.

PCI Hotplugging

Einige Computer erlauben das Wechseln von PCI-Geräten im laufenden Betrieb. Zum ordnungsgemäßen PCI-Hotplugging werden spezielle Kernelmodule geladen. Diese können für Nicht-PCI-Hotplug Computer schädlich sein. Da Hotplug-PCI-Steckplätze nicht automatisch entdeckt werden können, muss diese Funktion in /etc/sysconfig/hotplug manuell durch Setzen von HOTPLUG_DO_REAL_PCI_HOTPLUG aktiviert werden.

Coldplug

Coldplug kümmert sich um Geräte, die vor der Aktivierung des Hotplug-Systems angeschlossen wurden. Dies trifft stets während des Bootens zu. Coldplug kümmert sich auch um Geräte, die schwer zu entdecken sind.

Zuerst ruft Coldplug für jede statische Hardware-Konfiguration in /etc/sysconfig/hardware (hwcfg-static-*) das Skript hwup auf. Auf diese Weise kann man alte oder exotische Hardware initialisieren. Das kann auch hilfreich sein, um Geräte in einer bestimmten Reihenfolge zu initialisieren.

Die Skripte /etc/hotplug/*.rc suchen nach Geräten, die immer noch nicht initialisiert wurden und erzeugen für diese Geräte Hotplug-Events. Für PCI-Geräte gibt es eine White- und eine Blacklist mit Gerätetypen, die jeweils behandelt oder übersprungen werden sollen. Diese Listen werden in den Kommentaren in /etc/sysconfig/hotplug erläutert.

Die Skripte *.rc geben für jedes gescannte Gerät ein Zeichen aus:

  • . das Gerät ist bereits initialisiert und wird deshalb übersprungen
  • * erzeuge einen Hotplug-Event für dieses Gerät
  • W das Gerät befindet sich nicht in der Whitelist und wird deshalb übersprungen
  • B das Gerät befindet sich in der Blacklist und wird deshalb übersprungen

Konfiguration

/etc/sysconfig/hotplug

In dieser Datei befinden sich Variablen mit denen das Verhalten von Hot- und Coldplug verändert werden kann. Die Auswirkungen dieser Variablen werden in den Kommentaren in dieser Datei erklärt.

/proc/sys/kernel/hotplug

Hier ist der Name der ausführbaren Datei abgelegt, die vom Kernel aufgerufen wird.

Bootparameter

Dies sind einige Parameter, die am Boot-Prompt gesetzt werden können:

  • NOHOTPLUG=yes Wenn auf yes gesetzt, dann werden Hotplug-Events erst dann verarbeitet, wenn 'rchotplug start' manuell aufgerufen wurde.
  • NOCOLDPLUG=yes Wenn auf yes gesetzt, dann wird Coldplug übersprungen.
  • HOTPLUG_TRACE=<N> Wenn gesetzt, dann gibt Hotplug den Namen des Moduls, das geladen wird, auf der Konsole aus und wartet N Sekunden.

Debugging

Protokollierung

Unter der Standardeinstellung schreibt Hotplug nur wichtige Meldungen in die syslog. Um eine detailliertere Auskunft über die Arbeitsweise von Hotplug zu erhalten, setzen Sie HOTPLUG_DEBUG=yes. Falls Sie in irgendeinem Skript einen Bug vermuten, können Sie HOTPLUG_DEBUG=max setzen. Dann wird jedes Shellkommando von diesen Skripten protokolliert; das führt zu sehr vielen zusätzlichen Zeilen in der Protokolldatei.

Per Voreinstellung benutzt das Hotplugsystem syslog, mit anderen Worten, Sie finden alle Meldungen in /var/log/messages. syslog wird jedoch beim Booten erst nach Hot-/Coldplug gestartet, wodurch viele Meldungen verloren gehen. Deshalb können Sie HOTPLUG_SYSLOG auf einen anderen Wert setzen. Wegen weiterer Informationen lesen Sie bitte die Kommentare in /etc/sysconfig/hotplug.

Probleme während des Bootens

Wenn der Computer während des Bootens hängenbleibt, kann man am Bootprompt Hotplug (NOHOTPLUG=yes) und/oder Coldplug (NOCOLDPLUG=yes) ausschalten. Mit NOHOTPLUG wird verhindert, dass Hotplug Agenten aufruft, gleichgültig woher die Events kommen; die statischen Hardware-Konfigurationen (hwcfg-static-*) werden jedoch von Coldplug weiterhin ausgeführt. Wenn Hotplug später manuell gestartet wird (nicht durch Veränderung des Runlevels) dann wird NOHOTPLUG ignoriert. Mit NOCOLDPLUG wird Coldplug beim Booten übersprungen, das bedeutet, dass kein Gerätescan und keine statische Hardwarekonfiguration ausgeführt wird, Hotplug jedoch weiterhin arbeitet.

Wenn ein von Hotplug geladenes Modul der Schuldige ist, können Sie Hotplug beobachten, indem Sie am Bootprompt HOTPLUG_TRACE=<N> setzen. Dann gibt Hotplug den Namen des zu ladenden Moduls auf der Konsole aus und wartet N Sekunden bevor das Modul geladen wird. Einen interaktiven Modus gibt es nicht.

Der Eventrecorder

Es gibt ein Programm /sbin/hotplugeventrecorder, das von /sbin/hotplug und /sbin/hotplug-stopped stets aufgerufen wird. Wenn ein Verzeichnis /events existiert, so werden dort alle Hotplug-Events in eigenen Dateien protokolliert.