Hardware-Management unter Linux: Wie das System seine Geräte erkennt und nutzt

Prozessor, Arbeitsspeicher, SSD und Netzwerkkarte bilden die technische Grundlage eines Linux-Systems. Anwendungen arbeiten jedoch normalerweise nicht unmittelbar mit diesen Bauteilen. Zwischen Hardware und Software liegen mehrere Schichten: Firmware, Kernel, Treiber, Geräteschnittstellen und unterstützende Systemdienste.

Hardware-Management bedeutet deshalb mehr, als Geräte aufzulisten oder einen Treiber nachzuinstallieren. Es umfasst das Erkennen und Einbinden von Komponenten, die Verteilung ihrer Ressourcen, die Überwachung ihres Zustands und den kontrollierten Umgang mit Änderungen. Das Linux-Gerätemodell bildet dafür unter anderem Geräte, Busse und Treiber sowie ihre Beziehungen ab.

Dieser Beitrag liefert das Gesamtbild. Einzelne Werkzeuge und Konfigurationsschritte werden nur eingeordnet; ihre praktische Anwendung gehört in die Folgebeiträge.

Das Grundmodell: Von der Hardware zur Anwendung

Vereinfacht lässt sich das Zusammenspiel so darstellen:

Anwendungen und Systemdienste
              │
              ▼
Schnittstellen des Betriebssystems
Dateien, Netzwerk, Grafik, Audio, Gerätezugriffe
              │
              ▼
         Linux-Kernel
Ressourcenverwaltung, Subsysteme und Treiber
              │
              ▼
           Hardware
CPU, RAM, Controller und angeschlossene Geräte

Firmware ergänzt dieses Bild: Sie bereitet die Plattform beim Start vor oder stellt Funktionen innerhalb einzelner Geräte bereit. Manche Gerätetreiber müssen zusätzlich Firmware laden, bevor ein Gerät vollständig arbeiten kann.

Die wichtigste Unterscheidung lautet daher:

Ein Gerät kann physisch vorhanden und vom System erkannt sein, ohne bereits vollständig betriebsbereit oder für eine Anwendung nutzbar zu sein.

Dazwischen können beispielsweise eine fehlende Treiberbindung, benötigte Gerätefirmware oder eine noch nicht passende Konfiguration liegen. Das Gerätemodell unterscheidet entsprechend zwischen registrierten Geräten, verfügbaren Treibern und ihrer Zuordnung.

Welche Aufgaben übernimmt welche Schicht?

Die beteiligten Komponenten erfüllen unterschiedliche Aufgaben:

Schicht	Aufgabe
Plattform-Firmware	Bereitet die Hardware beim Start vor und liefert Informationen über die Plattform
Kernel	Verwaltet Prozessorzeit, Speicher und Gerätezugriffe
Treiber	Steuern bestimmte Geräte oder Geräteklassen und binden sie in Kernel-Subsysteme ein
Geräteverwaltung im Userspace	Reagiert auf Geräteereignisse und unterstützt die Einordnung und Bereitstellung von Geräten
Systemdienste	Übernehmen weiterführende Aufgaben, etwa die Verwaltung von Netzwerkverbindungen
Anwendungen	Nutzen die vom Betriebssystem bereitgestellten Funktionen

Ein neu registriertes Gerät kann beispielsweise ein Kernel-Ereignis auslösen, das die Geräteverwaltung im Userspace über die Änderung informiert. Unter vielen Distributionen übernimmt udev diese Rolle.

udev ist die dynamische Geräteverwaltung unter Linux. Sie reagiert auf Gerätemeldungen des Kernels und legt anhand von Regeln beispielsweise Zugriffsrechte und beständige Geräteverknüpfungen unter /dev fest – etwa beim Anschließen eines USB-Geräts.

Hardware-Management ist damit eine Zusammenarbeit mehrerer Ebenen – nicht die Aufgabe eines einzigen Programms.

CPU und Prozesse: Rechenleistung sinnvoll verteilen

Die CPU führt die Anweisungen laufender Programme und des Kernels aus. Für die Administration ist dabei nicht nur die Modellbezeichnung wichtig, sondern auch die Struktur der verfügbaren Recheneinheiten.

Zu unterscheiden sind insbesondere:

• Prozessorpakete beziehungsweise Sockel.
• Physische Prozessorkerne.
• Logische CPUs, beispielsweise durch Simultaneous Multithreading.
• Gemeinsame und getrennte Caches.

Linux stellt Informationen zur CPU-Topologie unter anderem über /sys/devices/system/cpu/ bereit. Die genaue Struktur hängt von der Architektur und der Hardware ab.

Wie hängen CPU und Prozesse zusammen?

Programme bestehen aus ausführbaren Threads. Der Scheduler entscheidet, welche davon auf welchen verfügbaren logischen CPUs laufen.

Damit verbindet sich Hardware-Management unmittelbar mit Prozessverwaltung: Es geht nicht nur darum, wie viele CPUs vorhanden sind, sondern auch darum, wie Rechenzeit verteilt und wie die Ausführung bestimmter Arbeitslasten begrenzt oder auf ausgewählte CPUs eingegrenzt wird. Dafür existieren unter anderem CPU-Zuordnungen und cgroup-basierte Steuerungsmöglichkeiten.

Auch bei Linux-Containern kommen cgroups zum Einsatz: Sie erfassen den Ressourcenverbrauch der Containerprozesse und können beispielsweise CPU-Nutzung und Arbeitsspeicher begrenzen. Konkrete Limits müssen entsprechend konfiguriert sein.

Welche Rolle spielt /proc/cpuinfo?

Die Datei /proc/cpuinfo stellt CPU- und architekturabhängige Informationen bereit. Sie ist eine Informationsschnittstelle des Kernels, keine gewöhnliche Konfigurationsdatei.

Ihre Felder sind nicht auf jeder Architektur identisch. Für das Gesamtbild ist deshalb wichtig, CPU-Informationen nicht ausschließlich aus einer einzelnen Datei abzuleiten.

RAM und Swap: Speicher ist mehr als eine Kapazitätsangabe

Der Arbeitsspeicher enthält unter anderem Programmdaten, Kernelstrukturen und zwischengespeicherte Dateiinhalte. Linux verwaltet ihn mithilfe virtueller Adressräume: Anwendungen arbeiten mit virtuellen Adressen, die auf physische Speicherbereiche abgebildet werden.

Daraus ergeben sich mehrere unterschiedliche Fragen:

• Wie viel physischer RAM ist vorhanden?
• Wie viel Speicher verwenden Anwendungen und Kernel?
• Welche Bereiche dienen als Cache?
• Welche Seiten können bei Bedarf freigegeben oder ausgelagert werden?
• Gibt es Speicherengpässe für das gesamte System oder nur für eine begrenzte Arbeitslast?

Ein hoher Speicherverbrauch ist daher nicht automatisch ein Problem. Dateicaches können beispielsweise Speicher belegen, der bei Bedarf wieder für andere Zwecke nutzbar gemacht wird.

Welche Aufgabe hat Swap?

Swap stellt zusätzlichen Platz für auslagerbare Speicherseiten bereit. Dadurch kann Linux bestimmte Inhalte aus dem RAM verdrängen, ohne sie sofort verwerfen zu müssen.

Swap ist aber kein gleichwertiger Ersatz für zusätzlichen Arbeitsspeicher. Für das Verhalten des Systems sind die Zugriffskosten des verwendeten Swap-Speichers und die Art der Arbeitslast entscheidend. Die Speicherverwaltung berücksichtigt deshalb unter anderem das Verhältnis zwischen Auslagerung und dem Verdrängen dateibasierter Seiten.

CPU und RAM gehören zusammen

Bei NUMA-Systemen ist Speicher nicht von jeder CPU aus gleich schnell erreichbar. Seine Zuordnung kann deshalb die Leistung beeinflussen.

Hardware-Management betrachtet CPU und RAM folglich nicht nur als zwei getrennte Kapazitäten, sondern auch als miteinander verbundene Topologie.

Busse und Controller: Wie Geräte angeschlossen sind

Ein Gerät hängt normalerweise nicht unmittelbar „an Linux“. Es ist über einen Bus, einen Controller oder mehrere aufeinanderfolgende Verbindungsebenen eingebunden.

Ein typisches Beispiel:

PCIe
  └── USB-Controller
        └── USB-Hub
              └── USB-Gerät

Der USB-Controller kann selbst ein PCI-Gerät sein. Das Linux-Gerätemodell bildet solche Beziehungen zwischen Bussen und Geräten ab.

Diese Struktur erklärt, warum eine Störung mehrere Geräte gleichzeitig betreffen kann: Die Ursache muss nicht im einzelnen Endgerät liegen, sondern kann auch eine gemeinsame Verbindungsebene betreffen.

PCI und PCI Express

Über PCI beziehungsweise PCI Express werden viele leistungsfähige Komponenten eingebunden, beispielsweise Netzwerkcontroller, Grafikprozessoren und Speichercontroller.

Das Werkzeug lspci gehört zur späteren Bestandsaufnahme dieser Geräte. Es beantwortet Fragen zur PCI-Seite eines Systems – nicht automatisch zur vollständigen Funktionsfähigkeit aller darauf aufbauenden Dienste.

USB

USB bildet eine weitere Geräte- und Verbindungshierarchie. Für die Übersicht über USB-Geräte dient lsusb.

Die Perspektiven ergänzen sich: Ein USB-Controller und ein daran angeschlossenes Gerät erscheinen auf unterschiedlichen Ebenen der Hardwarestruktur.

Nicht jede Hardware ist allerdings PCI oder USB. Das Kernel-Gerätemodell berücksichtigt auch andere Busse und plattformspezifische Geräte.

Speichergeräte: Vom Controller bis zu den Dateien

Beim Massenspeicher ist die Trennung der Ebenen besonders wichtig. Ein Laufwerk ist nicht dasselbe wie eine Partition, ein logisches Volume oder ein Dateisystem.

Eine mögliche Schichtenfolge lautet:

Controller und Laufwerk
          │
          ▼
      Blockgerät
          │
          ▼
Partition oder logische Speicherstruktur
          │
          ▼
gegebenenfalls Verschlüsselung und weitere Abbildungen
          │
          ▼
     Dateisystem
          │
          ▼
Mountpunkt im Verzeichnisbaum

Nicht jedes System verwendet alle diese Ebenen, und ihre Reihenfolge kann variieren. Linux kann physische und logische Blockgeräte über mehrere Abhängigkeiten miteinander verbinden; der Device Mapper stellt beispielsweise Abbildungen für logische Geräte bereit.

Für die Diagnose bedeutet das:

Ein erkanntes Laufwerk muss noch kein eingehängtes und nutzbares Dateisystem besitzen.

Umgekehrt kann eine Anwendung mit einem logischen Gerät arbeiten, hinter dem mehrere andere Speicherebenen liegen. Werkzeuge wie lsblk helfen später dabei, diese Beziehungen sichtbar zu machen.

Hardware-Management und Speicherverwaltung überschneiden sich hier, bleiben aber unterschiedliche Blickwinkel: Das eine betrachtet stärker Gerät, Verbindung und Treiber, das andere die darauf aufgebaute Organisation der Daten.

Netzwerkkarten: Hardwareerkennung ist noch keine Netzwerkverbindung

Auch bei Netzwerkkarten müssen mehrere Ebenen auseinandergehalten werden:

1. Das Gerät ist am Bus erkennbar.
2. Ein passender Treiber übernimmt es.
3. Der Kernel stellt eine Netzwerkschnittstelle bereit.
4. Die Verbindung wird konfiguriert.
5. Darauf aufbauende Kommunikation und Dienste funktionieren.

Die grundsätzliche Trennung zwischen Gerät, Treiber und bereitgestellter Funktion folgt dem Linux-Gerätemodell.

Eine funktionierende Treiberbindung beantwortet daher noch nicht, ob die gewünschte Netzwerkkonfiguration stimmt. Ebenso sollte bei einem Netzwerkproblem nicht vorschnell ein Hardwaredefekt angenommen werden.

Hardwaretreiber und Kernelmodule: Verwandt, aber nicht identisch

Ein Treiber enthält die Logik, mit der Linux ein bestimmtes Gerät oder eine Geräteklasse anspricht. Im Gerätemodell werden Geräte und Treiber miteinander verbunden, wenn sie zueinander passen.

Treiber können fest in den Kernel integriert oder als ladbare Kernelmodule bereitgestellt werden. Umgekehrt muss ein Kernelmodul kein Hardwaretreiber sein; auch andere Kernelfunktionen können modular vorliegen.

Diese Unterscheidung ist für die Interpretation der Werkzeuge wichtig:

Werkzeug	Wofür es gedacht ist
lsmod	Aktuell geladene Kernelmodule anzeigen
modinfo	Informationen über ein Kernelmodul ausgeben
modprobe	Kernelmodule unter Berücksichtigung ihrer Abhängigkeiten laden oder entfernen

Aus einer Modulliste allein ergibt sich noch kein vollständiges Bild der Hardwareunterstützung:

• Ein fest eingebauter Treiber erscheint nicht als geladenes Modul.
• Ein geladenes Modul muss nicht gerade ein bestimmtes Gerät betreiben.
• Die Zuordnung zwischen Gerät und Treiber ist eine zusätzliche Information.

Firmware: Nicht nur BIOS und UEFI

„Firmware“ bezeichnet im Hardwareumfeld unterschiedliche Dinge. Zwei Ebenen sollten zunächst getrennt werden.

Plattform-Firmware

BIOS beziehungsweise UEFI gehören zur Start- und Plattformumgebung des Rechners. In diesem Zusammenhang stehen auch Mechanismen, über die Linux Informationen über die Hardware erhält, etwa ACPI oder Device Tree.

Diese Begriffe sind nicht austauschbar: Sie betreffen unterschiedliche Teile der Plattformbeschreibung und der Zusammenarbeit zwischen Firmware und Betriebssystem. Die Kernel-Dokumentation behandelt Firmware sowie Firmware- und Device-Tree-Schnittstellen deshalb als eigene Themenbereiche.

Gerätefirmware

Daneben können einzelne Geräte eigenen Programmcode benötigen. Ein Treiber kann eine entsprechende Firmwaredatei anfordern und in das Gerät laden.

Daraus folgt eine wichtige Diagnosemöglichkeit: Der Treiber kann vorhanden sein, während die zusätzlich benötigte Firmware fehlt oder nicht geladen werden kann. Treiber und Firmware sind unterschiedliche Bestandteile der Geräteunterstützung.

Eine umfassende Bestandsaufnahme sollte deshalb nicht nur Hardwaremodell und Kernelversion berücksichtigen, sondern auch die beteiligte Firmware.

Interrupts und DMA: Wie Hardware mit dem Kernel zusammenarbeitet

Geräte müssen Daten übertragen und Ereignisse melden können. Zwei grundlegende Mechanismen sind Interrupts und Direct Memory Access.

Interrupts

Interrupts ermöglichen es unter anderem, die CPU auf Ereignisse aufmerksam zu machen. Damit gehören sie zur Zusammenarbeit zwischen Geräten, Prozessoren und Kernel.

Die Datei /proc/interrupts stellt Informationen über Interrupts bereit. Sie ist eine Diagnosequelle und keine Datei, in der man die Interruptverteilung wie einen gewöhnlichen Konfigurationstext bearbeitet.

DMA und IOMMU

Mit Direct Memory Access, kurz DMA, können Geräte Daten in dafür vorgesehene Speicherbereiche übertragen, ohne dass die CPU jedes einzelne Datenstück selbst kopieren muss.

Eine IOMMU (Input-Output Memory Management Unit) ist eine Hardwareeinheit zur Verwaltung von Speicherzugriffen durch Geräte. Sie übersetzt die Speicheradressen, die ein Gerät bei direkten Zugriffen auf den Arbeitsspeicher verwendet, in die entsprechenden physischen Speicheradressen. Gleichzeitig kann sie festlegen, auf welche Speicherbereiche das Gerät zugreifen darf. So lässt sich beispielsweise ein Gerät einer virtuellen Maschine zuweisen, ohne ihm Zugriff auf den gesamten Arbeitsspeicher des Hosts zu geben.

Diese Mechanismen machen deutlich: Hardware-Management umfasst nicht nur eine Liste von Komponenten, sondern auch deren Zusammenarbeit beim Zugriff auf Rechenleistung und Speicher.

/proc, /sys und Geräteereignisse: Die Sicht des Kernels

Linux stellt zahlreiche Hardware- und Zustandsinformationen über virtuelle Dateisysteme bereit.

Virtuelle Dateisysteme wie /proc und /sys stellen Systeminformationen und Steuerungsmöglichkeiten in Form von Dateien und Verzeichnissen bereit. Ihre Inhalte liegen nicht als gewöhnliche Dateien auf einem Datenträger, sondern werden vom Kernel bereitgestellt. So lassen sich beispielsweise Prozessdaten auslesen oder bestimmte Systemeinstellungen ändern.

Schnittstelle	Schwerpunkt
/proc	Prozessinformationen und verschiedene systemweite Kernelinformationen
/sys	Geräte, Treiber, Topologie und weitere Kernelobjekte

Manche Einträge sind reine Informationsquellen, andere erlauben Änderungen am laufenden System. Ein beliebiger Schreibzugriff oder das vermeintliche „Editieren einer Datei“ ist daher kein allgemeines Verwaltungsverfahren.

Energie, Temperatur und Betriebszustände gehören dazu

Eine Hardwarekomponente ist nicht nur vorhanden oder ausgefallen. Sie kann unterschiedliche Leistungs- und Energiesparzustände annehmen.

Zum Hardware-Management gehören deshalb auch:

• Die Abstimmung zwischen Leistung und Energieverbrauch.
• Das zeitweise Energiesparen einzelner Geräte.
• Systemweite Schlafzustände.
• Das zuverlässige Wiederaufnehmen des Betriebs.

Die Kernel-Energieverwaltung unterscheidet entsprechend zwischen gerätebezogenen Mechanismen und systemweiten Schlafzuständen.

Ein Problem, das ausschließlich nach dem Aufwachen oder nach längerer Inaktivität auftritt, sollte deshalb auch in diesem Zusammenhang betrachtet werden – nicht nur unter dem Gesichtspunkt „Treiber installiert oder nicht“.

Ressourcenverwaltung und Überwachung ergänzen die Geräteverwaltung

Ein Gerät kann technisch funktionieren und trotzdem für die aktuelle Arbeitslast nicht ausreichen. Deshalb sollten drei Fragen getrennt werden:

Frage	Blickwinkel
Ist die Komponente erkannt und eingebunden?	Geräte- und Treiberverwaltung
Welche Ressourcen werden tatsächlich genutzt?	Beobachtung von CPU, Speicher und Ein-/Ausgabe
Welche Ressourcen darf eine Arbeitslast verwenden?	Prozess- und Ressourcensteuerung

Mit cgroups kann Linux beispielsweise Ressourcenverbrauch erfassen und bestimmte Ressourcen begrenzen. Das betrifft nicht den physischen Einbau der Hardware, wohl aber ihre Nutzung durch Dienste und Anwendungen.

Gerade auf gemeinsam genutzten Systemen ist diese Verbindung wichtig: Hardwarekapazität allein erklärt noch nicht, wie viel davon einem bestimmten Dienst tatsächlich zur Verfügung steht.

Ein ganzheitliches Denkmodell für die Fehlersuche

Für Fehlerdiagnose kann mit folgenden Fragen entlang der einzelnen Schichten vorgenommen werden:

1. Ist die Komponente physisch beziehungsweise auf ihrer Verbindungsebene vorhanden?
2. Erkennt der Kernel das Gerät?
3. Ist ein passender Treiber zugeordnet?
4. Wird zusätzliche Firmware benötigt und erfolgreich geladen?
5. Stellt der Kernel die erwartete Schnittstelle bereit?
6. Ist die darauf aufbauende Konfiguration korrekt?
7. Tritt das Problem nur unter Last oder in bestimmten Energiezuständen auf?

Diese Reihenfolge verhindert, dass unterschiedliche Fehlerklassen miteinander vermischt werden. Sie folgt den Beziehungen zwischen Bus, Gerät, Treiber, Firmware und Systemverwaltung.

Nicht jedes Problem muss dabei auf der untersten Ebene beginnen. Entscheidend ist, Beobachtungen einer Schicht zuzuordnen und daraus die nächste sinnvolle Frage abzuleiten.

Fazit: Hardware-Management bedeutet, Beziehungen zu verstehen

Linux verwaltet Hardware nicht als lose Sammlung einzelner Geräte. CPU und Speicher, Busse und Controller, Treiber und Firmware sowie Systemdienste bilden ein zusammenhängendes System.

Das wichtigste Grundverständnis lautet: Vorhanden, erkannt, vom Treiber übernommen, konfiguriert und für Anwendungen nutzbar sind unterschiedliche Zustände. Wer diese Ebenen auseinanderhält, kann Informationen gezielter einordnen und Fehler systematischer untersuchen.

Die späteren Werkzeuge liefern dann nicht bloß Listen und Zahlen. Sie zeigen jeweils einen bestimmten Ausschnitt dieses Gesamtbilds.