ACPI: Power Management und Hot Plugging

Transcrição

ACPI: Power Management und Hot Plugging
Seminar Betriebssysteme SS2005
Roman Aspetsberger
Matr-Nr.: 0256309
SKZ: 033 521
[email protected]
10. Juni 2005
Stefan Preuer
Matr-Nr.: 0055832
SKZ: 880
[email protected]
Zusammenfassung
Es ist für uns alle schon fast selbstverständlich, dass man einen USB-Stick oder eine Digitalkamera an den laufenden PC ansteckt oder dass ein Notebook Alarm schlägt, wenn der Akku leer wird.
Dazu benötigt man aber Betriebssysteme und Hardware, welche perfekt miteinander kommunizieren
können. Dazu wurde von Hewlett-Packard, Intel, Microsoft, Phoenix, und Toshiba ein Standard entwickelt, welcher genau dies ermöglicht: ACPI - Advanced Configuration and Power Interface. In den
folgenden Kapitel wird genauer auf diese Spezifikation eingegangen und die Einflüsse dieser auf heutige, moderne Betriebssysteme aufgezeigt. Auch auf den Unterschied zum vorangegangenen Standard
APM wird eingegangen und die Vorteile von ACPI werden angeführt. Im zweiten Teil wird Hotplugging behandelt, welches bei einem modernen Betriebssystem nicht mehr wegzudenken wäre. Nach
dem zugrundeliegenden Hardwarevoraussetztungen werden verschiedene Geräte im Deteil behandelt,
unter anderem PCI, USB, Memory und CPU-Hotplugging. Zusätzlich soll eine Linuxfallstudie das
Thema Hot Plugging vom IO-Management über die Treiberentwicklung bishin zur Behandlung von
Hotplugging Ereignissen im UserSpace näher bringen.
INHALTSVERZEICHNIS
Inhaltsverzeichnis
1
2
ACPI
1.1 Powermanagement und Konfiguration . . . . . . . . . . . . . .
1.1.1 Grundsätzliche Ansatzmöglichkeiten - Firmware vs. OS
1.1.2 Das Powermanagement-Zustandsmodell von ACPI . . .
1.1.3 Einfluss von ACPI auf die Betriebssystemstruktur . . . .
1.2 Gerätekonfiguration . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
6
9
9
Hot Plugging
2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . .
2.1.1 Physikalische Voraussetzungen: . . . . . .
2.1.2 Änderungssensitivität der Hardware: . . . .
2.1.3 Eindeutige Geräteidentifkation: . . . . . .
2.1.4 Betriebssystemunterstützung: . . . . . . .
2.2 Hardwareseitige Systemintegration von Geräten . .
2.3 Beispiele für Hotplugging . . . . . . . . . . . . . .
2.3.1 PCI . . . . . . . . . . . . . . . . . . . . .
2.3.2 USB . . . . . . . . . . . . . . . . . . . . .
2.3.3 IEEE 1394/Firewire . . . . . . . . . . . .
2.3.4 Memory Hotplugging: . . . . . . . . . . .
2.3.5 CPU Hot-Plugging: . . . . . . . . . . . . .
2.3.6 Node Hotplugging . . . . . . . . . . . . .
2.4 Surprise Removal von Hardware . . . . . . . . . .
2.4.1 Caching Strategien . . . . . . . . . . . . .
2.5 Fallstudie: Linux Hot-Plugging . . . . . . . . . . .
2.5.1 Traditionelle Geräteeinbindung unter Linux
2.5.2 IO Management des Linux Kernels 2.6 . .
2.5.3 Treiber unter Linux . . . . . . . . . . . . .
2.5.4 Zusammenspiel Hot-Plugging - UserSpace
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
12
12
12
14
14
15
17
17
21
21
21
22
22
22
23
24
25
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
1
Kapitel 1
ACPI
1.1
Powermanagement und Konfiguration
Einerseits ist der bis heute im Wesentlichen unveränderte Bestand des bereits 1965 von Gordon Moore
aufgestellten berühmten „Gesetzes“, wonach sich alle 1.5 - 2 Jahre die Anzahl der verfügbaren Transistoren auf einem Chip verdoppelt, durchaus erstaunlich. Andererseits bringen die in Relation gesehenen kleinen Fortschritte im Bereich der mobilen Energieversorgung im Angesichte der besonders
starken Nachfrage nach mobilen und eingebetteten Systemen Ernüchterung in Bezug auf eine derartige Nutzung dieser immer leistungsfähiger werdenden digitalen Mikroelektronik. Die sich daraus
ergebende Herausforderung ist, die Kluft zwischen einer immer leistungsfähiger werdenden Hardware und einem aus Anwendungssicht vertretbaren Energieverbrauch zu überbrücken. Um dabei auf die
Leistungsfähigkeit moderner Hardware nicht verzichten zu müssen benötigt es grundsätzlich entsprechende Powermanagement-Funktionalitäten sowohl auf Seiten der Hardware als auch der Software
sowie insbesondere eine zielgerichtete Zusammenführung dieser. Der Inhalt dieses Kapitels bezieht
sich besonders auf das Advanced Configuration and Power Interface (ACPI) mit welchem versucht
wird eine derartige Schnittstelle zwischen Software und Hardware auf Computersystemen bereitzustellen. Das Ziel soll es dabei sein, ACPI von anderen Ansätzen abzugrenzen und somit gleichzeitig
Motivation für den Einsatz von ACPI zu schaffen, die Funktionalität von ACPI in einer für die Verständlichkeit nötigen Tiefe darzustellen, als auch die sich ergebenden Anforderungen an die Hardware
sowie im Besonderen an die Software zu verdeutlichen.
1.1.1
Grundsätzliche Ansatzmöglichkeiten - Firmware vs. OS
Entwicklungsverlauf von Powermanagement
Die Entwicklung von Powermanagement hat wie so oft sehr holprig begonnen was sich darin gezeigt
hat, dass es kein integriertes Konzept gegeben hat. So haben OEM’s begonnen individuelle Lösungen
für z.B. „Suspend-To-RAM“ oder „LCD-Display-blanking“ in die Systeme aufzunehmen. Prozessorseitig hat Intel mit der Einführung des Pentium-Prozessors einen unter der Bezeichnung System Management Modus (SMM) bekannten Prozessormodus unterstützt. In diesem Modus kann über einen
System-Management-Mode-Interrupt (SMI) gewechselt werden, welcher über einen eigenen Prozessoranschluss getriggert werden kann. In einem eigenen Adressraum für diesen Modus können dann
plattformspezifische Funktionen zum Power-Management realisiert werden. [Mes97].
Der erste Ansatz Powermanagement dem Betriebssystem in einer standardisierten Schnittstelle
zugänglich zu machen wurde 1992 durch das Advanced Power Mangagement (APM) Interface ge2
1.1. POWERMANAGEMENT UND KONFIGURATION
schaffen. APM hat grundsätzlich folgenden Konzeptuellen Aufbau:
Abbildung 1.1: Advanced Power Management System [MI96a]
Bei APM wird die Kernfunktionalität für das Powermanagement vom APM BIOS (Firmware)
bereitgestellt, wobei grundsätzlich das APM BIOS selbständig im Hintergrund das Powermangement
durchführt. Erweiternd ist es jedoch möglich, dass ein einzelner zentraler APM Treiber vom Betriebssystem für bestimmte Geräte die Kontrolle übernimmt, in dem dieser über das APM Interface APM
BIOS Routinen aufruft bzw. Statusinformationen abfragt (Polling). [MI96b]
Problematik des APM Ansatzes
• Real Mode Bios Aufrufe: Ein Problem bei APM ist, dass im Falle eines Aufrufes einer APM
BIOS Funktion durch das Betriebssystem (APM Treiber) dieses die Kontrolle an das APM
BIOS übergeben muss. Zusätzlich kommt es zu einem Wechsel des Prozessormodus, da heutige
Betriebssysteme im Protected-Modus laufen, die BIOS Routinen jedoch im Real Modus. Dies
ist insbesondere für die Betriebssystemhersteller jedoch nicht akzeptabel, da sie dadurch die
Betriebssystemstabilität stark abhängig von der Firmwarequalität machen. [GG03]
• Umfang: APM bietet eine sehr eingeschränkte Funktionalität und lässt insbesondere im Modus
der vollständigen Kontrolle durch das APM BIOS nur sehr einfache Scheduling-Strategien zu,
auch da entsprechende Kontextinformationen dazu nicht zugänglich sind. Dies ist insbesondere
auch dadurch begründet, dass die Firmware als Flash-ROM realisiert ist, wodurch sich aufgrund
der Technologie Beschränkungen hinsichtlich der Speichergröße und Flexibilität (Debugging)
ergeben.
Es ist also ersichtlich, dass APM inhärente Schwachstellen hat, welche hinsichtlich der heutigen Anforderungen insbesonders an mobile Computersysteme nicht akzeptabel sind. Im nächsten
Abschnitt wird nun auf das Advanced Configuration and Power Interface (ACPI) eingegangen mit
welchem versucht wird, die genannten Schwachstellen von APM zu umgehen.
3
Motivation für ACPI und OSPM
Das Advanced Configuration and Power Interface (ACPI) wurde in seiner ersten Version 1996 gemeinsam von Intel, Microsoft und Toshiba entwickelt. Mittlerweile liegt die Spezifikation seit September 2004 in der Revision 3.0 vor. ACPI ist eine umfangreiche Spezifikation, die sich nicht nur
auf Belange des Powermanagement bezieht, sondern ebenfalls eine Schnittstelle für die Konfiguration von Motherboard-Geräten darstellt. Eine wesentliche Intention ist dabei das Ersetzen von parallel
gewachsenen Systemkonfigurationsschnittstellen durch eine einheitliche, umfassende und adäquate
Schnittstelle und die Bereitstellung von leistungsfähigen und stabilen Möglichkeiten zum Powermanagement. Im Folgenden möchten wir besonders den Aspekt des Powermanagements betrachten.
Als besondere Schwachstelle von APM haben wir im vorigen Abschnitt die Abgabe der Kontrolle
an die Firmware und deren potenziell negative Auswirkungen auf die Systemstabilität, -konsistenz
und -effizienz angeführt. Um dieser Problematik zu entgegnen greift ACPI auf das in der Informatik
bewährte Konzept der Abstraktion zurück. Die grundsätzliche Überlegung dabei ist, anstatt Aktionen
direkt durch Implementierungen in der Firmware zu realisieren, die nötigen Schritte zur Abwicklung einer solchen Aktion über die Firmware dem Betriebssystem zu kommunizieren wonach dieses
die benötigten Schritte selbständig durchführen kann. Es bedarf also einer Beschreibungssprache für
Aktionen, welche Hardwareinteraktionsoperationen beinhalten. In ACPI übernimmt diese Rolle die
ACPI Machine Language (AML) welche eine bytecode-interpretierte Sprache darstellt. Die von ACPI
parallel dazu spezifizierte für den Menschen lesbare Sprache ist die ACPI Source Language (ASL)
welche man automatisch zu AML bytecode kompilieren kann. Wie aus Abbildung 2, welche die Abstraktionsebenen im Zusammenhang mit dem Powermanagement schematisch darstellt, ersichtlich ist,
wird die platformspezifische Hardwarezugriffsbeschreibung in einem vom jeweiligen Betriebsystem
zu implementierenden ACPI AML Interpreter ausgeführt, welcher die Schnittstelle zwischen dem Betriebssystem und dem eigentlichen Hardwarezugriff bereitstellt. Dem Betriebssystem werden nun auf
einer abstrakten Ebene über die Firmware derartige AML-Kontrollmethoden (engl.: controll methods)
für Aktionen im Zusammenhang mit dem Powermanagement zur Verfügung gestellt, welche es dann
im ACPI AML Interpreter ausführen kann um das gewünschte Ziel zu erreichen.
Abbildung 1.2: ACPI Abstraktionsmodell [GG03]
Diese Zugriffsart unterscheidet sich grundlegend von der Ansatzweise die etwa APM verfolgt. An-
4
statt für die Erledigung einer Aktion (z.B. den Batteriestatus abfragen) die Kontrolle an die Firmware
zu übergeben, werden hier in Bytecode-kompilierter Form die dazu nötigen Operationen beschrieben und dem Betriebssystem zugänglich gemacht, welches dann in einer sicheren Umgebung (ACPI
AML Interpreter) diesen, ohne die Kontrolle abzugeben, interpretierend ausführen kann. Aufgrund
der Bytecode-Kompilierung ist eine hohe Effizienz bei der Interpretation gewährleistet.
Laut [GG03] können die Vorteile wie folgt zusammengefasst werden:
• Höhere Kontrolle durch das Betriebssystem. Der AML Interpreter kann Fehler während der
Interpretation des AML-Codes abfangen und behandeln, anstatt bedingungslos der Firmware
ausgeliefert zu sein.
• Es können mehrere AML-Kontrollmethoden gleichzeitig in mehreren Threads ausgeführt werden und ankommende Hardware-Interrupts werden nicht blockiert. Dies ergibt sich dadurch,
dass AML-Interpretation im gleichen Prozessormodus wie das Betriebssystem ablaufen kann.
• Geringerer Firmwarespeicherbedarf ergibt sich aus der Tatsache, dass der AML-Bytecode entsprechend komplexe Operationen enthält, welche in der Firmware implementiert viel mehr
Speicher brauchen würden.
An dieser Stelle ist es noch nötig anzumerken, dass durch ACPI nicht zwingend die gesamte
Hardwareinteraktion über den beschriebenen Weg der AML-Interpretation erfolgt, sondern insbesondere für besonders geschwindigkeitssensible Aufgaben durch ACPI eine fixe Hardwareschnittstelle
festgelegt wird.
Besonders wichtig ist es zu betonen, dass ACPI lediglich eine Schnittstellendefinition ist, welche wie gerade beschrieben, eine sehr flexible Hardwareimplementierung erlaubt. ACPI schafft somit
nur die Grundvoraussetzung zum Powermanagement indem die Hardwareinteraktion festgelegt ist. Es
fehlt also noch die nötige und letztendlich entscheidende Logik für das Powermanagement, d.h. eine
Instanz, welche den aktuellen für das Powermanagement relevanten Systemzustand hält und entsprechend dieser Aktionen zur Optimierung des Energieverbrauchs, bei gleichzeitiger Beachtung der aktuell benötigten Leistung der Systemressourcen und etwaigen Benutzerpräferenzen, vornimmt sowie
entsprechend auf relevante Ereignisse der Hardware reagiert. Es ist nahe liegend, dass eine derartige
Instanz, um möglichst reichhaltige Kontextinformation für das Powermanagement zur Verfügung zu
haben, bestmöglich auf der Ebene des Betriebssystems einzugliedern ist. Man spricht in diesem Falle von „Operating System directed Powermanagement“ (OSPM). Die Ausprägung und Realisierung
von OSPM ist hochgradig betriebsystemabhängig, da es ein Bestandteil dieses ist und mit den anderen Betriebssystemkomponenten sowie Anwendungen interagieren muss. Ebenfalls sei erwähnt, dass
OSPM in der Regel nicht ein monolithischer Betriebssystemblock ist, sondern durchaus über mehrere Betriebssystemkomponenten wie etwa Gerätetreiber verteilt sein kann. OSPM bezeichnet somit
vielmehr das grundlegende Konzept, nach welchem das Betriebssystem sozusagen die Taktik für das
Powermanagement bestimmt. Als Gegensatz sei hier noch einmal das weniger leistungsfähige Konzept von APM erwähnt, in welchem hauptsächlich die Firmwareselbst über das Powermanagement
entscheidet. Da die Firmware jedoch nur wenig Information über die Anwendungs- sowie. Betriebssystemebene, welche letztendlich die treibende Ebenen hinsichtlich der benötigten Systemleistung sind,
hat, ist es konzeptuell unmöglich, auf dieser Ebene eine umfangreiche Powermanagement-Taktik zu
implementieren.
5
1.1.2
Das Powermanagement-Zustandsmodell von ACPI
ACPI verfolgt auch in der Bereitstellung eines Zustandsmodells bezüglich des Powermanagements
konsequent das Prinzip der Abstraktion, was aufgrund der Verschiedenartigkeit von Hardwaregeräten
sehr nahe liegend ist. Im Prinzip wird dabei der diesbezügliche Systemzustand durch ein Zustandsmodell kategorisiert. Folgende Abbildung zeigt dieses Zustandsmodell insbesondere für den globalen
Zustand:
Abbildung 1.3: Global System Power States und Transitionen [CCC+ 04]
Im Wesentlichen besteht das Zustandsmodell aus 5 grundsätzlichen Dimensionen, welche jedoch
in Ihren tatsächlich vorkommenden kombinierten Ausprägungen miteinander verkoppelt sind. Diese
5 Dimensionen mit ihren jeweiligen Ausprägungen sind:
• Global System State: G0 - G3
• Sleeping State: (S0), S1 - S4,(S5)
• Device Power State: D0 - D3
• Processor Power State: C0 - Cn
• Device and Processor Performance State: P0 - Pn
Wobei jedoch zu beachten ist, dass für jedes Gerät bzw. jeden Prozessor ein individueller Device
Power State bzw. Processor Power State sowie Device and Processor Performance State besteht.
6
Im Folgenden werden nun die einzelnen Zustandsdimensionen sowie deren Zusammenhang beschrieben [CCC+ 04]:
Global SystemState Global System States beziehen sich auf das gesamte System und sind für den
Benutzer deutlich wahrnehmbar. Man unterscheidet:
• G3 Mechanical Off: In diesem Zustand ist der Computer mechanisch von der Stromversorgung
getrennt. Es ist ein Betriebssystemneustart erforderlich, um wieder in den Working State zu
gelangen.
• G2 (S5) Soft Off: In diesem Zustand ist der Computer mechanisch mit einer Stromversorgung
verbunden, bezieht jedoch minimale Leistung von dieser - im Wesentlichen nur um ein elektronisches Einschalten zu ermöglichen. Prägend für diesen Zustand ist ebenfalls, dass der Systemkontext nicht durch die Hardware gesichert ist und folglich ein Neustart nötig ist um in
den Working State zurückzukommen. Im Prinzip ist dieser Zustand identisch mit dem tiefsten
Sleeping State S5, weshalb er auch oft so bezeichnet wird.
• G1 Sleeping: Dieser Zustand ist durch eine geringe Leistungsaufnahme geprägt, wobei jedoch
keine Usermode-Programme ausgeführt werden und eine Rückkehr in den Working State ohne
Betriebssystemneustart möglich ist. Um dies zu ermöglichen, muss der Systemkontext durch
Hardware und/oder Softwaremaßnahmen gesichert werden. Die nötige Latenz zum Zurückkehren in den Working State hängt von der Tiefe des Sleeping States ab und wird durch die
Dimension des Sleeping States ausgedrückt (S1 - S4), welcher also nur in diesem Global State
eine sinnvolle Bedeutung hat.
• G0 Working: Dies ist der einzige Global State in welchem Usermode-Programme ausgeführt
werden, also der Computer für den Benutzer Arbeit verrichten kann. Wobei in diesem Zustand
die Dimensionen Device Power State und Processor Power State eine sinnvolle Bedeutung erlangen, da die Leistungszustände der einzelnen Geräte sowie Prozessoren in diesem Zustand
dynamisch entsprechend der Powermanagement-Taktik angepasst werden können.
Sleeping State Sleeping States stellen eine Unterkategorisierung des Global State G1 (Sleeping)
dar, und unterscheiden sich für den Benutzer im Wesentlichen hinsichtlich der Latenzzeit zur Rückkehr in den Global Working State G0. Man unterscheidet folgende Sleeping States:
• S1 Sleeping State (Standby): Dieser Sleeping State hat die geringste Aufwachlatenzzeit. Entscheidend ist dabei, dass kein Systemkontext verloren geht, da er allein durch die Hardware
gehalten wird.
• S2 Sleeping State: S2 ist ähnlich zu S1, jedoch geht in diesem Sleeping State der CPU- und
Systemcache-Kontext verloren wodurch dieser durch das Betriebssystem vor dem Betreten gesichert werden muss.
• S3 Sleeping State (Suspend to RAM): S3 ist ebenfalls ähnlich zu S1 und S2, jedoch geht in
diesem Fall der gesamte Systemkontext, mit Ausnahme des Systemspeichers, verloren (CPU,
Cache und Chipsatz Kontext), und muss somit durch das Betriebssystem gesichert werden.
• S4 Sleeping State (Suspend to Disc): Dies ist der Sleeping State mit der geringsten Leistungsaufnahme und gleichzeitig der längsten Aufwachlatenzzeit. Um die Leistung auf ein Minimum
7
zu reduzieren werden dabei alle Geräte ausgeschaltet. Um aus diesem Zustand wieder ohne Betriebssystemneustart in den Working State zu gelangen, muss der gesamte System- und Plattformkontext auf einem nicht flüchtigen Speicher gehalten werden, weshalb man diesen Zustand
auch Non-Volatile Sleep nennt. Dieses Sichern des Kontextes wird üblicherweise durch das
Betriebssystem vorgenommen, wobei dazu meist eine Datei auf der Festplatte verwendet wird
(NVS File . . . Non-Volatile Sleep File). Wenn das System den Zustand wieder verlässt (üblicherweise angestoßen durch das Drücken des elektronischen Ein-/ Ausschaltknopfes), wird am
Beginn des Betriebssystemneustarts diese NVS File eingelesen und nach diesem der Kontext
vor dem Betreten von S4 wieder hergestellt. Da dieser Zustand auf nicht flüchtigem Speicher
beruht kann die Stromversorgung mechanisch getrennt werden und dieser Zustand grundsätzlich beliebig lang andauern, ohne eine Rückkehr in den Working State unter selbem Kontext
wie vor dem Eintritt in S4 zu gefährden.
Device Power State Jedes Gerät, welches im Rahmen von ACPI Powermanagement behandelt wird,
hat einen individuellen Device Power State, wobei dieser entsprechend den aktuellen Anforderungen
in der Regel benutzertransparent angepasst wird. Für alle Geräte haben die Device Power States D3
und D1 die selbe Bedeutung. So bezeichnet D3 (Off) den Zustand in welchem die Energieversorgung
vollständig vom Gerät entfernt wurde und somit der gesamte Gerätekontext verloren geht - dieser muss
also etwa vom jeweiligen Gerätetreiber vorher gesichert werden. D0 (Fully On) hingegen bezeichnet
den Zustand, in welchem das Gerät vollständig aktiv und damit auch den größten Energieverbrauch
hat. Zwischen diesen Extremen gibt es noch die Zustände D2 und D1, deren genaue Bedeutung für
diesbezüglich gleiche Klassen von Geräten definiert ist. Allgemein gilt jedoch, dass in D2 weniger
Energie verbraucht wird als in D1 und somit auch mehr an Gerätekontext verloren geht. Es sei noch
erwähnt, dass nicht jede Geräteklasse D1 und/oder D2 vorsehen muss.
Processor Power State Processor Power States sind vom Konzept her ähnlich zu den Device Power
States, beziehen sich jedoch speziell auf Prozessoren, welche hinsichtlich Energieverbrauch und Wärmeentwicklung eine besonders gewichtige Rolle in einem Computersystem spielen. Diese Zustände
stellen wiederum eine Unterkategorisierung innerhalb des Global Working State G0 in Bezug auf die
Prozessoren dar. Man unterscheidet folgende Abstufungen:
• C0 Processor Power State: Dies ist der einzige Processor Power State, in welchem die entsprechende CPU Instruktionen ausführt.
• C1 Processor Power State: In diesem Zustand werden keine Instruktionen ausgeführt und somit der Energieverbrauch reduziert. Die Latenzzeit um wieder nach C0 zu kommen ist nicht
genau festgelegt, sie muss aber so gering sein, dass sie für das Betriebssystem keinen Grund
für die nicht Verwendung von C0 darstellt. Softwareseitig hat dieser Zustand, außer dass keine
Instruktionen ausgeführt werden, keine Auswirkungen.
• C2 Processor Power State: C2 stellt gegenüber C1 einen erhöhten Energiespareffekt dar, wobei
nun jedoch die maximal auftretende Latenzzeit um wieder nach C0 zu kommen über ein ACPI
Firmware-Objekt bezogen werden kann und somit für das Betriebssystem als Entscheidungshilfe für den Eintritt in diesen Zustand herangezogen werden kann. Softwareseitig hat dieser
Zustand wie C1 außer dass keine Instruktionen ausgeführt werden könne keine Auswirkungen.
• C3 Processor Power State: In C3 wird nun der größte Energiespareffekt aber auch die längste
Latenzzeit, welche wiederum über die ACPI Firmware bereitgestellt wird, erreicht. Außerdem
8
1.2. GERÄTEKONFIGURATION
hat C3 die Konsequenz dass Sofwareseitig für Cache-Kohärenz gesorgt werden muss, da in
diesem Zustand die Hardware dies nicht mehr gewährleistet.
Device and Processor Performance State Performance States stellen eine Unterkategorisierung
der aktiven Device- bzw. Prozessorstates D0 bzw. P0 hinsichtlich Energieverbrauch und somit Leistungsfähigkeit dar. P0 ist dabei der Zustand in dem ein Gerät bzw. Prozessor die maximale Leistungsfähigkeit und somit den höchsten Energieverbrauch hat. P1 - Pn (wobei maximal 16 Performace States
möglich sind) stellen dann mit aufsteigender Nummerierung einen geringeren Energieverbrauch dar.
1.1.3
Einfluss von ACPI auf die Betriebssystemstruktur
Durch ACPI wird dem Betriebsystem eine umfangreiche Möglichkeit geboten den Energieverbrauch
eines Computersystems in Abwägung mit den Anforderungen und insbesondere der benötigten Performanz zu optimieren. Da jedoch ACPI nur die Schnittstelle ist, stellt es zwar eine Grundvoraussetzung für umfangreiches Powermanagement dar, überlässt es jedoch rein dem Betriebssystem diese
Möglichkeiten entsprechend zu nützen. Damit das Betriebssystem dieser Anforderung nachkommen
kann benötigt es eine entsprechende Abstimmung der Betriebssystemstruktur und insbesondere des
Gerätemodells des Betriebssystems. Besonders entscheidend ist dabei eine Repräsentation der physikalischen Geräteabhängigkeiten durch das Gerätemodell des jeweiligen Betriebssystems. Diese Notwendigkeit ist unmittelbar einleuchtend wenn man bedenkt dass ACPI die Reihenfolge in der Geräte
beispielsweise zum Zwecke des Energiesparens in einen Schlafzustand oder überhaupt ausgeschaltet
werden rein dem Betriebssystem überlässt. Dadurch ist zwar einerseits sehr hohe Flexibilität gegeben,
aber es ist zwingend notwendig, dass das Betriebssystem über die physikalischen Abhängigkeiten
zwischen den einzelnen Geräten bescheid weiß. Um ein einfaches einleuchtendes Beispiel zu nennen, darf beispielsweise der PCI-Bus erst dann abgeschaltet werden, wenn für alle Geräte zuvor der
jeweilige Kontext gespeichert wurde und diese abgeschaltet wurden. Aufgrund der üblichen hardwareseitigen Strukturierung von Computersystemen lassen sich diese Geräteabhängigkeiten in hierarchischen Strukturen darstellen. Eine derartige Struktur war und ist in vielen Betriebssystemen jedoch
nicht vorgesehen. In Windows wurde deshalb mit Windows 2000 auf ein neues Treibermodell mit dem
Namen WDM (Windows Driver Model) umgestellt, welches unter anderem eine derartige Hierarchie
unter den Geräten vorsieht. Unter Linux soll das seit dem Kernel 2.6 eingeführte neue Gerätemodell,
welches sich dem User als sys-Filesystem repräsentiert, diese Aufgabe erfüllen, ist jedoch trotz der
Präsenz in der aktuellen stabilen Kernelversion noch nicht vollkommen ausgereift. [GG03][Qua04]
Weiters ist es natürlich entscheidend, dass ein Betriebssystem einen ACPI AML Interpreter vorsieht
und in die Betriebssystemstruktur integriert, sowie dass es gemäß der ACPI-Spezifikation Zugriff auf
die ACPI-Firmware-Tabellen vorsieht. Die damit verbundene, nötige Integration in die Betriebssystem
ist jedoch stark betriebssystemspezifisch und würde den Rahmen dieser Seminararbeit sprengen.
1.2
Gerätekonfiguration
Wie der Name ACPI (Advanced Configuration and Power Interface) bereits verrät hat ACPI nicht
nur das Ziel umfangreiches Powermanagement zu ermöglichen. Zusätzlich zum Powermanagement
versucht ACPI eine einheitliche Möglichkeit zur Konfiguration von Motherboardgeräten festzulegen.
Dazu werden über das ACPI-Interface Kontrollmethoden und Information bereitgestellt um dem Betriebssystem (OSPM) eine entsprechende Möglichkeit zur Konfiguration von Geräten insbesondere
unter Berücksichtigung der Möglichkeit des dynamischen Hinzufügen und Entfernen von Geräten.
9
1.2. GERÄTEKONFIGURATION
Dabei werden diese Motherboardgeräte über sog. ACPI Definition Blocks, welche von der ACPIFirmware exportiert werden, beschrieben. Insgesamt ergibt sich dadurch ein Hierarchischer Zusammenhang aller Geräte. Als wichtige Information für Plug & Play werden dabei die nötigen Hardwareressourcen welche die Geräte verwenden können, sowie Objekte zur Konfiguration dieser bereitgestellt. Für diese Konfigurationsmethoden kann wiederum das flexible Konzept der Beschreibung durch
AML verwendet werden. Es sei an dieser Stelle noch erwähnt, dass diese von ACPI unterstützte Konfigurationsmöglichkeit nicht zwingend Verwendet werden muss sondern vor allem für Geräte welche
sonst keine effiziente Möglichkeit zur Aufzählung und Konfiguration bieten. So besteht beispielsweise für PCI Geräte keine Notwendigkeit mittels der ACPI Konfigurationsmöglichkeiten aufgezählt zu
werden. Auf diese Gerätekonfigurationsmöglichkeiten kann an in dieser Seminararbeit jedoch nicht
im Detail eingegangen werden. Für eine ausführliche Behandlung dieses Themas sei an dieser Stelle
auf die ACPI Spezifikation [CCC+ 04] verwiesen.
10
Kapitel 2
Hot Plugging
2.1
Allgemeines
Unter Hot-Plugging versteht man das Einfügen eines Gerätes in ein laufendes Computersystem wobei
die automatische Erkennung und Konfiguration erlaubt, dieses neu eingefügte Gerät ordnungsgemäß
verwenden zu können. Umgekehrt erlaubt es ebenso das Entfernen eines Gerätes aus einem laufenden Computersystem mit automatischer Deinitialisierung im System. Um diese Forderungen sinnvoll
erfüllen zu können bedarf es sowohl Maßnahmen von Seiten der Hardware als auch der Software (Betriebssystem). So sind im besonderen folgende Fähigkeiten für sinnvolles Hot-Plugging entscheidend
[wik05b]:
2.1.1
Physikalische Voraussetzungen:
Es muss physikalisch gesichert sein, dass das Einfügen bzw. Entfernen eines Gerätes über eine bestimmte Hardwareschnittstelle keine mechanischen und elektrischen Beschädigungen verursacht. Wobei man je nach Art der physikalischen Voraussetzungen oft auch zwischen Hot-Swapping vs. HotPlugging unterschieden wird, der Begriffsunterschied ist jedoch in der Literatur nicht konsistent definiert [lina]. Es ist aber ein prinzipieller Unterschied ob man physikalisch gesehen das Gerät ohne
Bedenken jederzeit einfügen oder entfernen kann (wie twa bei USB) oder ob es vorheriger Vorkehrungen wie etwa das Abschalten der Energieversorgung für das Gerät bedarf (wie etwa bei üblichen
hotplug-fähigen PCI Schnittstellen). Laut [lina] wird ersteres mit Hot-Swapping bezeichnet und letzteres mit Hot-Plugging. Aufgrund der inkonsequenten Trennung dieser Begriffe in der Literatur wollen auch wir diese Trennung nicht weiter verwenden, der prinzipielle Unterschied ist aber sehr wohl
entscheidend.
2.1.2
Änderungssensitivität der Hardware:
In modernen Computersystemen werden die meisten Geräte über umfangreiche Bussysteme in das
System integriert. Eine entscheidende Vorraussetzung für das Hot-Plugging ist damit, dass der Bus
das Einfügen und Entfernen von Geräten am Bus automatisch erkennt, was eine entsprechende Anforderung an das elektronische und logische Busprotokoll impliziert.
11
2.2. HARDWARESEITIGE SYSTEMINTEGRATION VON GERÄTEN
2.1.3
Eindeutige Geräteidentifkation:
Um eine Verbindung von neu in das System eingefügter Hardware und einer softwareseitig für die
Steuerung und Kontrolle dieser nötigen Softwarkomponente (Treiber) herstellen zu können, bedarf
es einer Identifikation dieser Hardware. Ist eine derartiger Identifikation nicht möglich, so müssen
aufwendig und technisch unsauber potentielle Treiber durchprobiert werden in der Hoffnung aufgrund
charakteristischer Merkmale (z.B. Antwortverhalten über bestimmten Registern) der Hardware den
richtigen Treiber zu finden. Ein Beispiel für eine derartige Identifikation wäre etwa die Vendor ID
und Device ID welche ein Gerät eindeutig identifiziert. Treiber können nun ID’s angeben welche sie
unterstützen, wodurch ein entsprechendes Mapping sichergestellt ist.
2.1.4
Betriebssystemunterstützung:
Letztendlich muss das Betriebssystem fähig sein auf derartige hardwareseitige Änderungen entsprechend zu reagieren. Dies bedingt einerseits das Erkennen, wann neue Hardware eingefügt bzw. entfernt wurde, sowie andererseits das Feststellen um welche Hardware es sich handelt um schließlich
einen entsprechenden Gerätetreiber für diese Hardware zu finden und in das System entsprechend
einzugliedern. Moderne Bussysteme ermöglichen dabei eine asynchrone interruptgetriebene Benachrichtigung des Betriebssystems über Hardwarekonfigurationsänderungen was sinnvolles Hot-Plugging
ermöglicht. Alte (Bus)Systeme konnten vom Betriebssystem jedoch nur durch aufwendiges Überprüfen des gesamten Systems auf Änderungen überprüft werden.
2.2
Hardwareseitige Systemintegration von Geräten
Wie bereits im vorigen Kapitel verdeutlicht wurde bedarf es grundlegender Voraussetzungen durch
die Hardware um technisch sauberes Hot-Plugging realisieren zu können. Um Hot-Plugging verstehen zu können ist es daher unumgänglich sich mit der hardwareseitigen Realisierung und Strukturierung von Computersystem auseinander zu setzen. Moderne Computersysteme sind in der Regel nach
der Hub-Architektur strukturiert, welche in Abbildung 4 schematisch dargestellt ist. Durch das meist
probrietäre Hub Interface ist dabei eine hohe Übertragungsgeschwindigkeit zu den über den ICH (I/O
Controller Hub) angeschlossenen Geräten und Bussystemen gewährleistet. Der Arbeitsspeicher hingegen wird direkt über den MCH (Memory Controller Hub) verbunden wodurch eine besonders hohe
Übertragungsrate zur CPU gewährleistet ist. Die Graphik welche ebenfalls eine besonders hohe Übertragungsrate benötigt ist entweder direkt in den MCH integriert, wobei man dann von einen GMCH
(Graphics Memory Controller Hub) spricht oder über ein eigenes Interface mit dem MCH verbunden
und (normalerweise AGP) in eine eigene Graphikkarte ausgelagert.
Ziel dieses Kapitel soll es nun nicht sein detailliert auf die hardwareseitige Realisierung von Computersystem einzugehen, sondern vielmehr einen kurzen Überblick über die Art der Integration von
Hardware zu geben, da sie das Kommunikationsmodell des Betriebssystemkernels mit der Hardware
entscheidend prägt. Der Zugriff auf die Geräteregister erfolgt üblicherweise über spezielle IO-Ports
oder durch Abbildung dieser Register auf Speicheraddressen (Memory-Mapped-IO), wobei die verwendete Technik vom jeweiligen Prozessor abhängt jedoch nichts am grundsätzlichen Konzept ändert,
dass der Prozessor Zugriff auf die Register des jeweiligen Hardwaregerätes erlangt. Zur asynchronen
Benachrichtigung der CPU über wichtige Ereignisse stehen hingegen Interruptleitungen zur Verfügung, welche über einen Interruptcontroller mit der CPU verbunden sind. Um eine entsprechende
systematische Integration von Geräten in das System zu ermöglichen werden diese üblicherweise
12
2.2. HARDWARESEITIGE SYSTEMINTEGRATION VON GERÄTEN
Abbildung 2.1: Hub-Architektur [har]
über Bussysteme angeschlossen. Solche Bussysteme sind beispielsweise PCI (Peripheral Component
Interconnect)oder USB (Universal Serial Bus).
Beides sind intelligente Bussysteme welche insbesondere ein entsprechendes Konfliktmanagement bereitstellen und somit unter anderem die Treiberprogrammierung erleichtern. Es besteht jedoch grundsätzlich ein wesentlicher Unterschied im Ansprechen von Geräten über den jeweiligen
Bus, welcher für unsere Betrachtung entscheidend ist. Nach [linf] unterscheidet man folgende Beide
grundsätzlichen Konzepte:
• Direktes Ansprechen der Geräte Ein Beispiel für diese Art der Gerätekommunikation ist der
PCI-Bus. In diesem Falle legt der Bus zwar neben dem physikalischen und logischen Busprotokoll einige Verwaltungsaufgaben fest, wie etwa die Ressourcenverwaltung oder das Erkennen
von neuen Geräten, jedoch werden die Geräte noch direkt angesprochen. So existiert etwa im
Falle von Memory-Mapped-IO ein bestimmter Speicherbereich in welchen die Register des
PCI-Gerätes abgebildet werden, moderne Bussystem erlauben dabei eine flexible Abbildung
um Ressourcenkonflikte möglichst zu verhindern.
• Kommunikation über Paketschnittstelle des Hostcontrollers Ein grundsätzlich anderer Ansatz
ist jener welche beispielsweise bei USB verfolgt wird. Bei Bussen dieser Art hat die CPU keine
Möglichkeit direkt auf die Register des jeweiligen Geräte am Bus. Stattdessen wird diese Aufgabe an den Hostcontroller delegiert, welcher über ein entsprechendes Busprotokoll mit den
einzelnen USB-Geräten kommuniziert. Im Falle von USB handelt es sich dabei etwa um ein serielles Bussystem mit Baumstruktur. Die CPU hingegen kommuniziert direkt nur mit dem Hostcontroller, welcher für diese direkt ansprechbar ist. Für diesen Zweck sind spezielle Hostcontrollerinterfaces definiert, welche das nötige Kommunikationsprotokoll festlegen. Entscheidend
13
2.3. BEISPIELE FÜR HOTPLUGGING
für unsere Betrachtung ist dabei dass sich durch diese Art der Systemintegration eine entsprechend saubere Abstraktion auf Treiberseite herstellen lässt. So gibt es einen Treiber, welcher
für die Ansteuerung des USB-Hostcontrollers zuständig ist. Im Falle von USB und Linux ergibt
sich dabei ein eigenes Subsystem (USB-Subsystem, usb-core). Von diesem Subsystem können
nun Funktionen in Anspruch genommen werden, welche es ermöglichen ein bestimmtes Gerät
logisch anzusprechen (abstraktere Schnittstelle) - der Core-Treiber kümmert sich dann um die
entsprechende Kommunikation mit dem Hostcontroller welcher als Vermittler agiert. Weiters
wird das USB-Subsystem vom Host-Controller über neu erkannte Geräte bzw. entfernte Geräte verständigt, wodurch ein sauberes Hotplugging ermöglicht wird. Der Core-Treiber bzw. das
entsprechende Subsystem informiert dann potentiell zuständige Treiber über das neu erkannte
Gerät bzw. stößt eine Suche nach einem passenden Treiber an. Aufgrund dieser Abstraktionsschicht lassen sich sehr komplexe Busse mit relativ einfachen Gerätetreibern realisieren, da
diese lediglich eine logische Sicht auf das Gerät haben und sich nicht selbst um die Geräteerkennung kümmern müssen sondern darüber informiert werden. Besonders interessant für das
Hotplugging ist dabei auch dass Geräte entsprechende Metainformationen über sich und ihre
Schnittstellen bekannt geben, was für ein adäquates Finden von Treibern und eine passenden
betriebssystemseitige Systemintegration äußerst entscheidend ist.
Nachfolgend wird nun eine genauere Betrachtung dieser Bussysteme in Hinblick auf Hotplugging
durchgeführt und auf Memory und CPU Hotplugging eingegangen.
2.3
Beispiele für Hotplugging
Es gibt verschiedenste Geräte, welche hotpluggingfähig sind. Einige davon werden in den hier folgenden Kapitel beschrieben:
2.3.1
PCI
PCI Hot Plugging wird ein immer wichtigerer Faktor für das PCI Bus System. Deswegen wird intensiev an dieser Technologie geforscht unter anderem von der „PCI Special Interest Group“, welche
einen Standard für PCI Hot Plug liefern. (derzeit in Version 1.1) Über 900 Firmen sind Mitglieder
in der SIG![sig] Auch Compaq ist einer der Spitzenreiter auf diesem Gebiet und Begründer der SIG,
was man auch an der Anzahl von veröffentlichten Whitepapers sieht. Einige davon sind auch hier
referenziert. Beim PCI Hot Plugging findet man oft 3 verschiedene Arten:
• Hot Replacement: Hot Replacement ist das Austauschen eines Geräts mit einem identischem
zum Beispiel im Falle eines Defektes. Dies ist der günstigste Fall, da hier keine anderen Treiber
zum Einsatz kommen müssen.
• Hot Upgrade: Ein vorhandenes Gerät wird durch ein anderes, unterschiedliches ausgetauscht,
was auch den Austausch der Treiber im Betriebssystem nachsich zieht.
• Hot Expansion: Hier wird an einem noch freien PCI-Slot ein Gerät hinzugefügt.
Während die PCI Hot Plug Spezifikation der SIG nur die technischen Vorraussetzungen beschreibt,
liefert Compaq auch eine Art Standard für die Implementierung der Hardware: Dabei ist es möglich,
die Stromversorgung eines jeden PCI Slots einzeln zu steuern, was das Hotplugging ansich leichter
macht, aber auch einen positiven Nebeneffekt hat: Fehler in der Stromversorgung beim Hotplugging
14
Abbildung 2.2: PCI Hot Plug Technologie [Com98]
(z.B. Kurzschluss durch defekte Karte) können meist vom slot-spezifischen Controller abgefangen
werden und wirken sich nicht auf das Gesamtsystem aus. Über ein User-Interface (oder durch Buttons
an der Hardware bei neueren Serversystemen) kann dem Betriebsystem mitgeteilt werden, dass das
Gerät im Slot aktiviert bzw. deaktiviert werden soll. Das Betriebssystem teilt dies nun dem Hot Plug
Controller mit, welcher unter anderem die zum Slot gehörende Power Control informiert. Oft findet
man für jeden Slot noch Status-LEDs vor, welche anzeigen, ob das Gerät entfernt werden darf, oder
nicht. Eine vereinfachte Darstellung dazu in Abbildung 2.2
Beispiel: Compaq PCI Hot Plug Driver für Windows 2000 Server
Die Verbindung zwischen User Interface, Betriebssystem und Hardwarecontrollern wollen wir nun
noch ein bisschen genauer betrachten. Dazu verwenden wir die schematische Darstellung eines Compaq Drivers für ein Windows 2000 Server Betriebssystem. Der Treiber für die PCI Hot Plug Geräte
steuert den Hardware Controller, welcher wiederum die einzelnen Slot Controller bedient. Zusätzlich ist der Hot Plug Driver eine Art Funktionsschicht zwischen den Windows Treibern und dem
Kernel, welcher zusätzliche Funktionen bereitstellt und den Kernel mittles Events über Änderungen
informiert.[Com99] Der Rest wird bereits von Windows zur Verfügung gestellt. Mittels Plug and Play
Events und Request funktioniert die Kommunikation zwischen User- und Kernel Mode. Der User
Mode PnP Manager liefert dann schon fertige Operationen, welche von den Applicationen verwendet
werden. Diese müssen nicht, wie in Abbildung 2.3 gezeigt, ausschließlich von Microsoft stammen, da
man durch die Win32 API auch selbst darauf zugreifen kann.
2.3.2
USB
Der Universal Serial Bus (USB) ist ein Bussystem zur Verbindung eines Computers mit externen
USB-Peripheriegeräten zum Austausch von Daten. Durch die relativ hohen möglichen Datenraten
und die automatische Erkennung von Geräten und deren Eigenschaften ist der USB zum Anschluss
fast aller Gerätearten von Maus und Tastatur bis zu Lautsprechern, Festplatten und Foto-Kameras
vorgesehen. USB 1.1 wird von Windows ab Version 98se unterstützt, wobei aber bereits bei Windows
95 eine rudimentäre und sehr fehlerbehaftete Unterstützung für USB 1.0 vorhanden war. Windows
2000 mit Service Pack 3 und Windows XP (SP 1) unterstützen nun auch den neuesten Standard 2.0.
15
Abbildung 2.3: PCI Hot Plug Architecture für Windows 2000 Server [Com99]
Linux unterstützt seit seiner Kernelversion 2.4 gängige USB Geräte, wobei aber auch schon bei früheren Kernelversionen (z.B. 2.2) USB Controller teilweise unterstützt wurden. Grundsätzlich können an
einen USB Port bis zu 127 Geräte angeschlossen werden, was allerdings eher ein theoretischer Wert
ist, da die Betriebssysteme meist schon viel früher überlastet sind. Der zweite große Vorteil neben
den relativ hohen Übertragungsraten (z.B. USB 2.0 mit bis zu 480 MBit/s) ist, dass alle Geräte hot
plugging fähig sind. Dies wird durch den Host Controller und die eigenen Adressierungs- und Sendestrategien verwirklicht. Ein weiterer Aspekt, warum USB so erfolgreich wurde, ist wohl die Tatsache,
dass über diesen Anschluß Geräte bis zu einer Grenze von meist 100mA/Gerät bzw. 500mA/Port mit
Strom versorgt werden können.
Host Controller/Adressierung
Die Realisierung des Hot Plugging liegt in der Architektur des Host Controllers. Da die USB Geräte
sich einen seriellen Bus teilen, ist es Aufgabe des Host Controllers, diesen auf die Geräte aufzuteilen.
Deswegen darf ein USB Gerät nur dann senden, wenn es vom Host Controller abgefragt wird. Entdeckt nun der Host Controller ein neues Gerät an einem Port, sendet er ein Reset an dieses, wodurch
die Adresse auf 0 gesetzt wird. Es werden hier 7bit-Adressen verwendet, wodurch sich die möglichen 127 Geräte erklären lassen. Nach dem Reset versucht der Controller das Gerät zu identifizieren,
wodurch das Betriebssystem die richtigen Treiber laden kann. Danach bekommt es eine eindeutige Adresse zugewiesen. Da immer nur ein Port mit noch nicht konfiguriertem Gerät aktiviert wird,
kommt es zu keinen Adresskollisionen. Zusätzlich können noch so gennante Device-Deskriptor, welche z. B. die Hersteller- und Produkt-ID enthalten, abgefragt werden. Dies dient etwa zur Bestimmung
der Geräteklasse.
Damit nicht für jede Maus, Tastatur oder andere Standardgeräte ein eigener Treiber geladen werden muss, wurden verschiedene Geräteklassen eingefürt, welche generische Treiber enthalten, die für
16
alle Geräte einer Klasse die Grundfunktionen bieten. Dies hat den Vorteil, dass nicht jedesmal, wenn
man zum Beispiel eine Maus an den USB-Port anschließt, für diese eine spezielle Maus ein Treiber
installiert werden muss, sondern die Maus sofort mit ihren Grundfunktionen benutzt werden kann.
Bietet ein solches Gerät noch Zusatzfunktion, welche nicht Standard für diese Klasse sind (z.B. Maus:
weiter Funktionstasten), dann muss man allerdings den dazugehörigen Treiber installieren, falls man
diese Zusatzfunktionen nützen will. [usb00][wik05c]
2.3.3
IEEE 1394/Firewire
Anders, als oft angenommen, ist FireWire und IEEE 1394 nicht das selbe. IEEE 1394 ist ein Standard
für ein Bussystem, welcher teilweise ähnlich, teilweise aber auch sehr unterschiedlich zu USB ist.
FireWire ist der von der Firma Apple geprägter Markenname für eine in den Funktionen reduzierte
Implementierung des Schnittstellen- und Protokollstandards IEEE 1394. Anfangs war der IEEE 1394
durch seine höhere Übertragungsgeschwindigkeit gegenüber USB im Vorteil, doch mit USB 2.0 wurde
IEEE 1394a (mit 400Mbit/s) um 80 Mbit/s überholt. Allerdings gibt es auch bereits den Standard IEEE
1394b, welcher mit (zukünftigen) Geschwindigkeiten von bis zu 3200 Mbit/s auf sich aufmerksam
macht. IEEE 1394 zeichnet sich ebenfalls wie USB durch hohe Hotplugging und Removal Fähigkeiten
aus, wodurch wir es hier erwähnen wollen.[wik05a][app]
Ähnlich wie bei USB funktioniert auch das HotPlugging unter FireWire. Da aber hier die Kommunikation nicht zentral gesteuert wird, sondern Geräte auch direkt miteinander kommunizieren können,
ist es nötig, dass nach einem Hotplugging Event alle Geräte neu konfiguriert werden. Dies geschieht
in 3 Phasen: Zuerst wird ein Reset versandt, worauf die Phasen „Tree-ID“ und „Self-ID“ folgen. Beim
Tree-ID wird die Topologie der angeschlossenen Geräte bestimmt, wobei ein Rootknoten bestimmt
und ein Baum mit Eltern und Kindports aufgebaut wird. Dabei ist ein Kind-Port immer mit einem
Knoten verbunden der weiter vom Root-Knoten entfernt ist als der jeweilige Eltern-Port. In der SelfID Phase wird nun die locale Adresse bestimmt und mit den direkten Nachbarn kommuniziert. (vgl.
dazu Routing Algorithmen) Die dabei gewonnenen Informationen werden mittels Broadcast an alle vorhandenen Knoten weitergegeben. Danach kann durch die gewonnenen Informationen über die
Topologie direkt zwischen 2 Geräten kommuniziert werden.[Wef00]
2.3.4
Memory Hotplugging:
Da vor allem bei wichtigen Serversystemen Stehzeiten sowohl einen hohen Image- als auch Geldverlust zur Folge haben können und größere Systeme sogar über 30 Minuten zum Reboot benötigen, wird
vor allem bei solchen Systemen gefordert, einen Großteil der Hardware auch zur Laufzeit auszutauschen. Deswegen unterstützen neueste Betriebssysteme wie Windows Server 2003 Memory Hot-Add.
Auch auf dem Linuxsektor laufen bereits einige Projekte, welche die Realisierung dieser Aufgaben in
Angriff nehmen. Damit das Betriebssystem Memory Hotplugging unterstützen kann, muss natürlich
die Hardware entsprechend dafür ausgelegt sein und das Bios dies unterstützen.
Memory Hot-Add:
Damit ein Betriebssystem Memory-Hotplugging unterstützen kann, muss das Bios gewisse Anforderungen erfüllen [Mic04]:
• Das Bios muss eine Static Resource Affinity Table, kurz SRAT, zur Verfügung stellen, in welcher sich Informationen zum möglichen Speicher (als auch zu Prozessoren) befinden.
17
• Der Speicher muss in Memory Device Objects, wie in der ACPI Spezifikation 3.0 im Kapitel
9.13 beschrieben ist [CCC+ 04], definiert sein.
• Das Bios muss natürlich auch das Betriebssystem informieren, welcher physischer Speicher zur
Verfügung steht. (E820)
Wird nun ein Speicherblock hinzugefügt, laufen folgende Schritte ab:
• Das Bios muss das Betriebssystem informieren, dass Speicher hinzugefügt wurde. Dies geschieht über ein ACPI Notify auf das Memory Device Object, welches den Speicher beschreibt.
• Nun muss das Betriebssystem überprüfen, ob das Memory Device Object anzeigt, dass der
Speicher verfügbar ist.
• Ist dies der Fall, müssen die Treiber (Plug and Play) für das Memory Device Object geladen
werden.
• Der Memory Manager wird vom Memory Device Object Driver informiert, dass sich der Speicherbereich geändert hat.
• Anschließend wird der neue Speicher vom Memory Manager für das Betriebssystem verfügbar
gemacht und kann nun normal verwendet werden.
Static Resource Affinity Table [Mic03]
Die SRAT enthalten Informationen über die Anordnung von Prozessoren und Speicher. Wobei es
möglich ist, Prozessoren und Speicher in Domains einzuteilen, was bei verteilten Systemen zur Anwendung kommt. Außerdem kann hier Speicher als Hot Pluggable definiert werden, weshalb sie hier
erwähnt werden.
Aufbau: Die Static Recource Affinity Tabelle hat einen Header, welcher eine Signatur, Prüfsummen, ID’s und andere Headerinformationen enthält und genau 48 Byte lang ist. Danach folgen die
eigentlichen Informationen, welche hintereinander in bestimmten Strukturen für die verschiedenen
Informationen wie Prozessor oder Memorybereich angeführt sind. Siehe dazu Tabelle 2.1
Header
Resource Allocation Structure[n]
Größe (in Byte)
48
–
Beschreibung
Enthält eine Signatur, die Länge der gesamten Tabelle, eine Checksumme und
IDs und verschiedene Revision-Flags.
Nach dem Header folgt eine Liste von
Structures, welche die Informationen zu
den Prozessoren (für jeden Prozessor eine Structure) bzw. zu den Speicherbereichen.
Tabelle 2.1: Begin der SRAT
18
Memory Affinity Structure: Für das Memory Hotplugging sind die Strukturen für die Speicherbereiche entscheidend. Dieser Typ von Struktur hat die Nummer 1 und ist 40 Byte lang. Zusätzlich ist
hier eine Domain anzugeben, welche für NUMA Systeme wichtig ist. NUMA steht für Non Uniform
Memory Acces und beschreibt Systeme, deren Prozessoren zu den Speicherbereichen verschieden
günstige Zugriffsmöglichkeiten besitzten und deswegen ein Prozessor mit den günstigeren Memorybereichen in eine Domain eingeteilt werden, um die Performaz zu steigern. Falls es sich nicht um
ein NUMA-System handelt, sollte in der Memory Affinity Structure der Wert nach der Länge bei
0 belassen werden. Zwischen 2 reservierten, aber unbenützten Bereichen wird der zu beschreibende
Speicherbereich anhand seiner physikalischen Adresse (von - bis) angegeben. Dann folgt der für das
Hotplugging entscheidende Flags: Byte 1 der Flags zeigt, ob der Speicherbereich verwendbar, also
Enabled ( = 1) oder Disabled (=0) ist. Ist diese Flag auf 0 gesetzt, wird diese Memory Affinity Structure vom Betriebssystem einfach ignoriert, was die Erzeugung durch das BIOS vereinfacht. Das 2.
Flagbyte zeigt, ob dieser Speicherbereich Hot Pluggable ist, oder nicht. Die letzten beiden Bytes der
Flags sind nicht in Verwendung. Siehe dazu Tabelle 2.2
Größe (in Byte)
1
Type
Length
Proximity
main
1
Do-
1
Reserved
Base
Address
Low
Base
Address
High
Length Low
Length High
Reserved
Flags
5
4
Reserved
8
Beschreibung
1 für Memory Affinity structure (0 wäre Processor Local APIC/SAPIC Affinity
Structure)
Wert 40, da Memory Affinity Structure
ist 40 Byte lang.
Hier kann die Zugehörigkeit zu einer Domain angegeben werden. (bei Einprozessorsystemen standardmäßig auf 0)
4
4
4
4
4
Hier stehen die für uns entscheidenden
Informationen, ob der Speicherbereich
benutzbar bzw. Hot Pluggable ist.
Tabelle 2.2: Memory Structure in der SRAT
Adressierung bei Memory Hotplugging (Nonlinear)
Speicher muss nicht in der Reihenfolge der Speicherbänke hinzugefügt werden. Dies lässt allerdings
das Problem entstehen, dass „Löcher“ (Bereiche, welche nicht benutzt werden) in der physikalischen
Adressierung auftreten können. Der Speicher ist also nicht kontinuierlich vorhanden. Linuxsysteme
benutzen eine mem_map, welche ein Array von page-Strukturen darstellt, wobei jede physisch vorhandene Page einen Eintrag in der mem_map benötigt. Würde man nun die mem_map einfach für die
19
maximal verfügbare Speichergröße anlegen, käme man bei kleinen Systemen schnell an die Grenzen
des vorhandenen Speichers, da die mem_map 1% des dargestellten Speichers benötigt. Um dieses
Problem zu lösen, wurde zu den 3 bisherigen Repräsentationen einer physikalischen Adresse (die
Adresse selbst, die struct page bzw. die page frame nuber = Index der page in der mem_map) ein viertes Schema hinzugefügt, welches die lineare (also auf die physische Adresse bezogene) Page Frame
Number in eine möglicherweise kleinere (Index der mem_map) umrechnet. Dies kann durch kleinere
Sets erreicht werden. [HKC]
Memory Hot-Removal
Schwieriger als das Hinzufügen von Speicher ist das Entfernen des Speichers zur Laufzeit. Da der
Speicher ja wichtige Daten und die laufenden Anwendungen bis hin zu Teilen des Kernels enthalten
kann, müssen vor dem Entfernen des Speicherblocks die darin enthaltenen Pages gesichert werden.
Der Speicherblock, welcher entfernt werden sollte, kann aber verschiedene Arten von Pages enthalten,
welche unterschiedlich schwierige Routinen zum Verschieben der Pages benötigt. Clean Pages, also
Seiten, welche nur eine Kopie von Daten der Disk darstellen, als auch swapped Pages (Seiten, welche
bereits auf der Disk gesichert wurden) können leicht entfernt werden. Auch Pages, welche geswapped
werden können, sind durch den Page-Allocator leicht verschoben. Der Unterschied zu den normalen
Routinen liegt nur darin, dass ein ganzer Bereich freigemacht werden muss. Es darf also auch nicht
derzeit freier Speicher auf dem zu entfernenden Block benützt werden.
Abbildung 2.4: Das Verschieben einer Seite im Speicher [lhm04]
Es gibt aber auch Pages, welche nicht verschoben werden können. (z.B. Teile des Kernels) Liegen nun solche Seiten im Speicherblock, welcher entfernt werden soll, kann dieser nicht zur Laufzeit
entfernt werden. Würden diese Teile nun im ganzen Speicher verteilt liegen, also auf jedem Speicherblock ein gewisser Teil, dann wäre kein Block mehr Hot-Removal fähig. Aus diesem Grund muss der
Page Allocator versuchen, diese Teile zu gruppieren. Somit versucht man, Removable Areas einzuführen, welche keine solchen wichtigen Seiten enthalten und deswegen Hot-Removalfähig bleiben.
20
2.4. SURPRISE REMOVAL VON HARDWARE
2.3.5
CPU Hot-Plugging:
Die selbe Motivation, welche für Memory Hotplugging angeführt wurde, kommt auch beim Hotplugging von CPUs zur Geltung, wobei dies noch mehr ein Thema für große Serversysteme darstellt und
noch mehr in der Entwicklung als in konkreten Realisierungen steckt. Auf dem Linuxsektor gibt es
hier aber bereits vielversprechende Projekte welche sich mit diesem Thema beschäftigen.
Auch hier muss man wieder zwischen Hot-Add und Hot-Removal unterscheiden, da das Hinzufügen einer CPU wieder einfacher ist, als das Entfernen.
CPU Hot-Add
Nachdem vom Bios ein Hotplug Event ausgelöst wurde, muss zuerst gesichert werden, dass kein
zweites Hotplug Event gleichzeitig behandelt wird. Danach wird überprüft, ob die CPU verwendbar
ist und auch noch nicht hinzugefügt wurde. Danach müssen Kernel-Threads (z.B. für den Scheduler
der einen CPU,..) angelegt werden, welche die eine CPU bedienen. Dann wird die CPU in einer
globalen cpu_online_map registriert, damit das System die CPU auch einsetzten kann. Nun müssen
noch die neuen Kernel-Threads gestartet werden und das System darüber informiert werden, dass eine
neue CPU online ist. Erst jetzt kann ein neues Hotplug Event verarbeitet werden. [osd04]
CPU Hot-Removal
Wesentlich schwieriger, als das Hinzufügen einer CPU ist das Entfernen einer solchen. Bevor überhaupt mit dem Entfernen einer CPU begonnen werden kann, muss das System für kurze Zeit eingefroren werden, damit dieser CPU nicht weitere Prozesse zur Verarbeitung zugeteilt werden, bis diese
aus der cpu_online_map entfernt wurde. Wiederum muss sichergestellt werden, dass nur ein Hotplug
Event gleichzeitig behandelt wird. (Ansonsten könnte z.B. passieren, dass sich 2 CPUs gegenseitig
entfernen wollen!) Außerdem muss überprüft werden, dass nach dem Entfernen noch mindestens 1
CPU übrig bleibt. Sobald die CPU aus der cpu_online_map entfernt wurde, muss verhindert werden, dass diese noch mit dem System kommuniziert und Interrupts senden kann. Deswegen wird
sie deaktiviert, bevor das System wieder weiterlaufen kann. Der Scheduler muss nun die Tasks aus
der Workingqueue der zu entfernenden CPU an andere CPUs weitergeben. Außerdem werden nicht
mehr benötigte Kernel-Threads (z.B. Workingqueue-Thread der CPU) gekillt und dass System darüber informiert, dass eine CPU entfernt wurde. Nun könnte das nächste Hotplugging Event bearbeitet
werden. [osd04]
2.3.6
Node Hotplugging
Unter Node Hotplugging versteht man das Hinzufügen/Entfernen ganzer Knoten zur Laufzeit wobei
solch ein Knoten (ACPI Container) aus einer Kombination von CPUs, Speicher und I/O-Controllern
besteht. [lhn04]
2.4
Surprise Removal von Hardware
Ein weitaus größeres Problem, als das Hinzufügen von Hardware, stellt das unerwartete Entfernen von
Hardware, zur Laufzeit dar. Ein Beispiel dazu wär das Entfernen eines USB-Sticks oder einer externen
Festplatte, während darauf geschrieben oder davon gelesen wird, was im besten Fall nur einen Datenverlust aber auch zum Absturz des ganzen Systems führen kann, falls das Betriebssystem (bzw. der
21
2.5. FALLSTUDIE: LINUX HOT-PLUGGING
Treiber) dies nicht richtig abfängt.[MT02] Eine Lösung dieses Problems wäre eine hardwareseitige
Sperre, welche das Entfernen des Geräts nur dann erlaubt, nachdem dieses im Betriebssystem abgemeldet wurde. Diese Möglichkeit ist aber für die meisten Hotplugging-Geräte einfach zu umständlich
und teuer, oder einfach nicht realisierbar.[Mic01b] Man denke nur daran, dass jeder USB-Port einen
eigenen Sperrmechanismus besitzten müsste, welcher Softwaregesteuert funktioniert. Allerdings hilft
dieser auch nicht, wenn zum Beispiel eine externe Festplatte durch Trennen der Stromversorgung
„entfernt“ wird. Deswegen müssen Maßnahmen getroffen werden, um in solchen Fällen das System
stabil zu halten. Dies sollte bereits bei den Treibern geschehen. Dort ist ein weiterer Ansatz, das Problem mit dem surprise removal von Hardware zu lösen, „sanity checks“ einzuführen. Dies ist aber
auch nicht für alle Codeteile möglich, da dies die Treiber unglaublich aufblähen würde und diese dadurch sehr langsam werden würden. Deswegen muss hier abgewogen werden, wo ein solcher check
sinnvoll ist und wo nicht.
2.4.1
Caching Strategien
Bei Speichergeräten wird of Caching verwendet, um die Geschwindigkeit zu steigern. Es werden also
die Daten nicht gleich auf das Gerät (USB-Festplatte, Speicherkarten, . . . ) geschrieben, sondern mit
einer Kopie auf der Festplatte / Arbeitsspeicher gearbeitet. Dadurch wird der Nachteil von langsamen Verbindungen etwas aufgehoben. Erst später, wenn mehr Zeit dazu vorhanden ist, werden die
Daten auf das Speichergerät geschrieben. Dies wird aber in Anbetracht von Suprise Removal zum
Problem, da hier der Datenverlust (am Speichergerät) größer, als vielleicht nötig, ist. Deswegen sollte bei schnellen Datenspeichern wie IEEE 1394 Festplatten („FireWire“) generell davon abgesehen
werden und auch bei anderen Geräten das bißchen Gewinn an Performanz, das höhere Risiko eines
Datenverlustes rechtfertig. [Mic01b][Mic01a]
2.5
2.5.1
Fallstudie: Linux Hot-Plugging
Traditionelle Geräteeinbindung unter Linux
Eine generelle Philosophie hinter Unix bzw. Linux ist es, dem Benutzer über Filesysteme eine möglichst einfache und einheitliche Schnittstelle, sowohl zu physisch auf Speichermedien existente Dateien als auch zu Systeminformationen und Peripherie, zu bieten. So werden Geräte unter Linux traditioneller Weise über Gerätedateien, welche normalerweise unter dem Verzeichnis /dev angesiedelt
sind, angesprochen. Diese Gerätedateien besitzen als Attribute eine 8 Bit breite Major-Device-Number
sowie eine 8 Bit breite Minor-Device-Number. Dabei stellt die Major-Device-Number den Verweis
zu einem Gerätetreiber im Kernel dar, welcher sich in der Initialisierungsphase unter der gleichen
Nummer beim Kernel registriert hat. Die Minor-Device-Number stellt einen Parameter für den angesprochenen Treiber dar, dessen Interpretation jedoch grundsätzlich dem Treiber überlassen ist. Üblicherweise jedoch unterscheidet ein Treiber danach welches konkrete Gerät angesprochen werden
soll. So wird beispielsweise bei einem IDE-Festplattentreiber die Minor-Device-Number zur Unterscheidung der Festplatten und Partitionen auf diesen verwendet. Der Zugriff auf ein Gerät über eine
derartige Gerätedatei erflogt nun grundsätzlich mit den selben Systemcalls wie der Zugriff auf gewöhnliche Dateien. Der Kernel erkennt jedoch aufgrund eines Flags, dass es sich um eine Gerätedatei
handelt und ruft nach dem Überprüfen der Filesystemzugriffsrechte die dem Systemcall entsprechende Funktion in dem mit der Major-Device-Number der Gerätedatei beim Kernel registrierten Treiber
auf. Eine übersichtliche Darstellung der diesbezüglich interessanten Systemcalls kann [linc] entnommen werden. Traditionellerweise wurde nun ein Treiber entweder fix in den Kernel kompiliert oder
22
seit der Einführung der ladbaren Kernelmodule explizit durch entsprechende Scripte (etwa während
dem Systemstart) bzw. durch den Benutzer über entsprechende Kommandos geladen. Zusätzlich muss
sicher gestellt werden, dass für den Treiber eine entsprechende Gerätedatei (mit der gleichen MajorDevice-Number wie die mit der der Treiber beim Kernel reserviert ist) vorhanden ist bzw. erzeugt
wird. Erschwerend kommt hinzu, dass viele Applikationen für Geräte ganz bestimmte Namen der
Gerätedateien voraussetzen.
Aus dem traditionellen Ansatz lassen sich folgende Fragen und Probleme erkennen:
• Wie können vielseitige Funktionen moderner Geräte über einfache Dateizugriffe realisiert werden?
• Mit 8 Bit breiter Major-Device-Number lassen sich theoretisch lediglich 256 Treiber und in
Verbindung mit der Minor-Device-Number maximal 65536 Geräte ansprechen.
• Wie kann ein Konflikt zwischen Treibern welche die selbe Major-Device-Number verwenden
verhindert werden?
• Hot-Plugging erfordert die durch ein Hot-Plugging-Ereignis getriebene Gerätekonfiguration
was das genaue Gegenteil des benutzergetriebenen Laden von Gerätetreibern ist.
Um die in einem modernen Linuxsystem vorhandenen Lösungen für die gerade angeführten Probleme
verstehen zu können, bedarf es einer zumindest überblicksartigen Betrachtung des IO-Managemets im
Linux-Kernel, was Gegenstand des nächsten Kapitels ist.
2.5.2
IO Management des Linux Kernels 2.6
Das IO Management ist jener Teil des Betriebsystemkernels, welcher für den Datenaustauch der Programme mit der Peripherie, also den Geräten, zuständig ist, wobei sich dessen Aufgaben im Wesentlichen in folgende Beide abstrahieren lassen:
• Ein Interface für die systemkonforme Integration von Hardware anbieten.
• Eine einheitliche Programmierschnittstelle für den Zugriff auf die Peripherie zur Verfügung zu
stellen.
Beide Aufgaben erfordern also die Bereitstellung einer entsprechenden Schnittstelle. Im ersten Fall
zwischen Hardware und Betriebssystem im Zweiten hingegen zwischen Betriebssystem und den Applikationen. Um standardisierte Schnittstellen zu schaffen bedarf es dabei entsprechender Abstraktion.
In frühen Unix Zeiten war die Sache relativ einfach. Dabei wurden Geräte grundsätzlich lediglich in
zwei Kategorien unterschieden - Charcter Devices und Block Devices, wobei erstere nur reinen sequentiellen Zugriff erlauben, letzere hingegen zusätzlich ein freies Positionieren. Für heutige Computersysteme mit äußerst komplexen Geräten ist diese grobe Kategorisierung jedoch unzureichend. Aufgrund der Verschiedenartigkeit der Geräte, sowie der Art wie diese üblicherweise über Bussysteme an
das Computersysteme angeschlossen sind, wurde das IO-Management des Kernels in unterschiedliche Subsysteme unterteilt, welche auf die jeweiligen Individualitäten abgestimmt sind. Beispiele für
derartige Subsysteme sind: Character-Devices, Block-Devices, Netzwerk, SCSI , USB-Subsystem,
PCI-Subsystem, . . . Aufgrund der Vielfalt der Subsysteme musste auch die Applikationsschnittstelle erweitert werden, wobei folgende Differenzierung gegeben ist: Standard-API (open, close, read,
write und ioctl Systemcalls), Kommunikations-API, Card-Services und Multimedia-Interfaces (z.B.
Video4Linux). Um nun jedoch das Systemcall-Interface nicht zu sehr erweitern zu müssen, sind die
23
Interfaces zumeist auf Basis standardisierter Datenstrukturen und IO-Controls realisiert. IO-Controls
sind dabei über Dateideskriptoren ausgeführte Systemcalls namens ioctl, welche mit einer Kommandonummer und einen Zeiger auf einen Datenbereich zum Austausch standardisierter Datenstrukturen
zwischen Applikation und Treiber parametriesierbar sind. Auf diese Art können äußerst flexible Interaktionen über Gerätedateien ermöglicht werden.
Häufig ist auch der Fall, dass die hauptsächliche Interaktion mit einem Gerät nicht direkt mit einer
Applikation erfolgt, sondern durch andere Kernelsubsysteme. Beispiele hierfür wären etwa Blockgeräte auf welchen über ein Filesystem zugegriffen wird (typischer Zugriff auf eine Festplattenpartition)
oder der Zugriff auf Netzwerkgeräte über die Kommunikations-Stacks des Netzwerk-Subsystems. Im
Falle eines Netzwerktreibers ist es also nötig, dass sich dieser beim Netzwerksubsystem anmeldet um
über diesen Weg entsprechend der Intention in das System integriert zu sein [ling].
Ein Verständnis dieser grundsätzlichen Gliederung des IO-Managements in Subsysteme ist notwendig um den Ablauf von Hot-Plugging unter Linux verstehen zu können. Der Umfang dieser Seminararbeit erlaubt dabei natürlich nur eine übersichtliche Darstellung. Eine genauere Beschäftigung
mit diesem Thema sowie der Treiberprogrammierung unter Linux 2.6 kann [linb] entnommen werden.
Als nächstes wollen wir uns näher mit Treibern und deren Bezug zu den IO-Subsystemen unter Linux beschäftigen, da diese nach einem Hot-Plugging Ereignis für die meisten Geräte letztendlich die
Kontrolle über diese übernehmen müssen und somit eine entscheidende Rolle für das Funktionieren
von Hot-Plugging darstellen.
2.5.3
Treiber unter Linux
Grundsätzlich können Treiber unter Linux entweder fix in den Kernel kompiliert sein oder durch
ladbare Kernelmodule realisiert sein. Im ersten Fall spricht man auch von Built-in Treibern. BuitIn Treiber werden heutzutage meist nur noch für Geräte verwendet welche bereits beim Booten des
Betriebssystems benötigt werden. Als Kernelmodule realisierte Treiber erlauben nämlich eine hohe
Flexibilität des Systems und verhindern das der Kernel zu groß wird, außerdem ermöglichen Sie einen
dynamischen Treiber-Entwicklungsprozess.
Kernelmodule müssen nun keine Treiber sein. Treiber werden sie erst dadurch, dass sie sich
während der Modulinitialisierung unter anderem mit einer eindeutigen Identifikationsnummer beim
IO-Management des Kernels anmelden. Diese eindeutige Nummer entspricht traditionell der MajorDevice-Number unter welcher der Treiber infolge angesprochen werden kann. Aufgrund der bereits
besprochenen Beschränkung dieser auf 8 Bit wurde dieses Konzept mit der Kernelversion 2.6 jedoch
durch eine sogenannte 32 Bit breite Gerätenummer ersetzt, außerdem gibt es das Konzept der MinorDevice-Number nicht mehr. Es muss jedoch erwähnt werden, dass das neue Konzept der Gerätenummer zwar Kernelintern bereits realisiert ist, da jedoch Filesysteme und Applikationen noch mit dem
alten Major/Minor-Device-Number-Konzept arbeiten wird vorübergehend eine eindeutige Abbildung
dieser auf die Gerätenummern verwendet [lind].
Die Rolle der IO-Subsysteme beim Hot-Plugging Im traditionellen Ansatz war es die Aufgabe
des Treibers während seiner Initialisierungsphase eine Hardwareerkennung nach von ihm unterstützer
Hardware vorzunehmen.
Entsprechend mussten die damit verbundenen Hardwareressourcen wie etwa IO-Ports, IRQ’s, IOMemorybereiche und DMA-Kanäle reserviert werden, um Konflikte zu vermeiden. Erst dann konnte
ein Treiber die Hardware über die von ihm reservierten Ressourcen ansprechen. Nach diesem Ansatz
wird also ausgehend von einer Konfiguration und einem Treiber nach einem entsprechenden Gerät gesucht. Es ist klar ersichtlich, dass dieser Ansatz das genaue Gegenteil zum Prinzip des Hot-Plugging
24
darstellt. Nach diesem versucht man ausgehend von einem neu entdeckten Gerät einen entsprechenden
Treiber, eine Konfiguration und die nötige Systemintegration zu finden. Mit zunehmender Komplexität der Computersysteme ist es wie besprochen notwendig, das IO-Management in spezifische Subsysteme zu unterteilen. Eine ebenfalls für das Hot-Plugging entscheidende Unterteilung ist es dabei
Subsysteme für die einzelnen Bussysteme, über welche üblicherweise Peripheriegeräte angeschlossen werden, zu schaffen. Diese Subsysteme (z.B. PCI-Subsystem) übernehmen nun das Erkennen
von Hardware am entsprechenden Bussystem. Die Konsequenz daraus ist, dass es nun nicht mehr
die Aufgabe der Gerätetreiber ist ihre unterstützten Geräte zu erkennen. Dadurch erleichtert sich die
Programmierung der Gerätetreiber besonders auch dadurch, dass das Konfliktmanagement bezüglich
der von der Hardware beanspruchten Ressourcen zentral in den Subsystemen gehalten werden kann,
wobei moderne Bussystemen hierzu eine Hardware- bzw. Bios-seitige Lösung vorsehen welche das
Subsystem unterstützt.
Viel entscheidender für unsere Betrachtung ist jedoch, dass dadurch die Vorraussetzung für das
Hot-Plugging geschaffen ist, nämlich ausgehend von der Erkennung bzw. Entfernung eines Gerätes
einen entsprechenden Treiber für dieses zu initialisieren bzw. zu deinitialisieren. Im Linux Kernel
wird dies nun dadurch realisiert, dass sich ein Hot-Plugging fähiger Treiber bei seiner Initialisierung
beim entsprechenden Subsystem anmeldet. Entdeckt das Subsystem nun ein neues Gerät bzw. die
Entfernung eines vorhandenen Gerätes meldet dieses dem Gerätetreiber über eine registrierte Callbackroutine dieses Ereignis und übergibt im Falle des Erkennens eines neuen Gerätes die nötigen Informationen zum Ansprechen des Gerätes. Der Gerätetreiber reserviert daraufhin die eventuell damit
verbundenen Hardwareressourcen und initialisiert das Gerät - Treiber und Geräteinitialisierung sind
nun also getrennt. Der genaue Ablauf für gängige Bussysteme wie PCI und USB kann dabei [ling]
entnommen werden. Wie weiß das Subsystem nun aber welcher Treiber für das gefundene Gerät Unterstützung anbietet? An diesem Punkt kommt nun die im einleitenden Kapitel als Voraussetzung für
sinnvolles Hot-Plugging angegebene eindeutige Geräte-Identifikation ins Spiel.
So bieten moderne Bussysteme wie PCI und USB die Möglichkeit, dass Identifikationsdaten der
angeschlossenen Geräte standardisiert bereitgestellt werden. Bei PCI ist dies beispielsweise die Vendor ID und Device ID, über welche die Hersteller Geräte kennzeichnen können. Wenn sich ein Treiber beim entsprechenden Subsystem registriert, werden dabei die vom Treiber unterstützten Geräte
in Form derartiger Identifikationsmerkmale übergeben, wodurch das Subsystem Information über für
ein erkanntes Gerät in Frage kommende Treiber erhält. Ein weiterer erschwerender Punkt ist dass es
nicht reicht alleine Subsysteme für physikalisch unterscheidbare Bussysteme zu schaffen, da es auch
abstraktere Konzepte gibt, die nicht auf der Ebene der direkten Verbindung zu einem Gerät abhandelbar sind. Typische Beispiele dafür sind etwa das Netzwerksubsystem über welches Netzwerkgeräte
angesprochen werden oder das Blockgeräte üblicherweise über Filesysteme angesprochen werden. In
diesen Fällen muss sich der Treiber ebenfalls bei dem entsprechenden abstrakten Subsystem anmelden, sodass über eine dabei entstehende Schnittstelle über ein solches abstraktes Konzept auf das Gerät
zugegriffen werden kann. Die eigentliche Hardwareerkennung bleibt jedoch grundsätzlich gleich und
wird vom Subsystem, welches für den entsprechenden physikalischen Bus zuständig ist, durchgeführt.
2.5.4
Zusammenspiel Hot-Plugging - UserSpace
Bis jetzt haben wir uns rein mit der Kernel Ebene und dessen Erweiterung durch Module (Treiber)
beschäftigt. Es gibt nun jedoch noch eine Menge von Aspekten welche sich nicht sinnvoll auf Kernelebene lösen lassen sondern eine Interaktion mit dem Userspace erfordern, um unter anderem höhere
Flexibilität und Funktionalität zu ermöglichen. Nach [sf1]sind dabei folgende Aufgaben zu betrachten:
25
Treiber an Geräte binden Wie im vorigen Kapitel besprochen können die einzelnen Subsysteme
bei Erkennen neuer Geräte aufgrund von Geräteidentifikationsmerkmalen geeignete Treiber auswählen. Damit dies funktioniert müssen diese jedoch geladen sein, ansonsten können diese nicht beim
jeweiligen Subsystem registriert sein. Es bedarf also einer Lösung welche die nötigen Treiber in den
Kernel lädt.
Treiberspezifische Konfigurationsaufgaben Viele Treiber benötigen ein bestimmte Vorraussetzungen um ordnungsgemäß arbeiten zu können. Dies kann beispielsweise der Download von Firmware, das Starten eines zugehörigen Dämons oder die Bereitstellung bestimmter Konfigurationsparameter sein.
Gerätespezifische Konfigurationsaufgaben Treiber können grundsätzlich für mehrere physische
Geräte zuständig sein wodurch zusätzlich zu den treiberspezifischen Konfigurationsaufgaben für die
nun tatsächlich behandelten Geräte hinzukommen können.
Subsystemspezifische Konfigurationsaufgaben Diese Konfigurationsaufgaben beziehen sich gewöhnlich auf abstraktere Subsystem wie etwas das Netzwerk-Subsystem oder das Filesystem. Beispielsweise müssen Netzwerkschnittstellen entsprechend dem Netzwerkprotokoll konfiguriert werden
(z.B. mit ifconfig für IP-Konfiguration aus dem Userspace). Ein anderes Beispiel wäre dass Speichergeräte in das Filesystem eingehängt werden müssen, da sie üblicherweise über diese angesprochen
werden (mounten).
Starten von Applikationen Oft ist es auch wünschenswert, dass als Reaktion auf Hot-Plugging
Ereignisse Applikationen gestartet werden. So wäre es z.B. denkbar dass beim Anschließen einer Digitalkamera über USB eine Applikation zum Betrachten und speichern der Bilder auf der Kamera
gestartet wird.
Aus den angeführten Beispielen ist klar ersichtlich dass sich dies rein auf Kernelebene nicht sinnvoll lösen lässt. In Linux geht man deshalb den Weg, dass die Subsysteme des IO-Management HotPlugging Ereignisse auslösen, welche im Userspace behandelt werden können. Schematisch ist dies
für den Fall eines neu entdeckten PCI-Gerätes und der Aufgabe einen Treiber für dieses Gerät zu
laden in Abbildung 2.5 dargestellt:
Das PCI-Subsystem im Kernel erkennt also ein neues Gerät und erzeugt für dieses ein HotpluggingEreignis welches im Userspace behandelt wir. Dabei wird es zuerst vom Hotplugging Multiplexer
(Hotplug) an den dem Ereignis entsprechenden Hotplugging Agenten (pci.agent) weitergeleitet, welcher in diesem Beispiel einen benötigten Treiber lädt. Im folgenden Kapitel soll nun das Userspace
Hotplugsystem unter Linux genauer betrachtet werden.
Userspace Hotplugsystem unter Linux
Wie im vorigen Kapitel erklärt wurde ergeben sich zahlreiche Aspekte wie auf ein Hotplugging Ereignis reagiert werden soll. In aktuellen Linux-Versionen wird dazu das Dreiergespann linux-hotplug,
udev und HAL eingesetzt um eine entsprechende Integration von Hotplugging im System zu erreichen. Die standardmäßige linux-hotplug Implementierung basiert dabei auf dem Linux Hotplugging
Projekt [sf1] und setzt sich grundsätzlich aus einem Ensemble aus Shell-Scripts und speziellen Konfigurationsfiles zusammen. Für die Erzeugung, Entfernung und Benennung von Gerätedateien sowie die
26
Abbildung 2.5: Hot-Plugging Mechanismus [line]
Umbenennung von Netzwerkschnittstellen neu entdeckter bzw. entfernter Geräte wird zusätzlich ein
spezielles System namens udev eingesetzt [KH03]. Zur Integration der Hardwareebene in die abstraktere System- und Desktop-level Software und der entsprechenden Reaktion dieser auf Änderungen
in der Hardwarekonfiguration wird weiters HAL (Hardware Abstraction Layer) verwendet. Abbildung 2.6 macht den Zusammenhang dieser 3 Systeme deutlich, welche im Folgenden überblicksartig
beschrieben werden.
Hotplug (Linux Hotplugging Project) Zunächst ist es wichtig die Schnittstelle zwischen Kernel und Userspace zu erklären. Unter Linux in der Kernelversion 2.6 ruft dabei das HotpluggingSubsystem im Falle eines Hotplugging-Ereignisses jenes Userspace Programm auf, welches über das
Pseudofilesystem /proc unter /proc/sys/kernel/hotplug angegeben wird. Dieser Wert wird üblicherweise durch die Startscripts beim Booten des Systems auf den gewünschten sog. Hotplugdaemon gesetzt.
Diesem Hotplugdaemon wird dabei als Argument die Bezeichnung des initiierenden Kernelsubsystems übergeben (z.B. usb im Falle des USB-Subsystems). Außerdem wird über Umgebungsvariablen
das Ereignis detaillierter charakterisiert. So wird z.B. für ein Ereignis des USB-Subsystems über eine
Umgebungsvariable namens ACTION durch die Werte add bzw. remove festgelegt ob ein USB Gerät
hinzugefügt oder entfernt wurde. Besonders interessant für eine adäquate Behandlung des Ereignisses sind im Falle von USB etwa auch die über die Umgebungsvariablen DEVPATH und DEVICE
übergebenen Werte welche den Pfad zum Device-Eintrag im virtuellen sysfs-Dateisystem bzw. zum
Konfigurationseintrag im virtuellen proc-Dateisystem enthalten. Sysfs ist dabei ein virtuelles Dateisystem welches seit der Kernelversion 2.6 über das neue Gerätemodell in den Linux-Kernel Einzug
erhalten hat. Dieses neue Gerätemodell präsentiert sich dem Userspace eben über das sysfs, welches
üblicherweise über /sys gemountet ist. Über dieses Filesystem werden dem Benutzer einer Vielzahl
von Informationen über die dem Kernel bekannten Geräte, Schnittstellen und Treiber sowie deren
Zusammenhang bereitgestellt.
27
Abbildung 2.6: Zusammenhang hotplug, udev, HAL [Zeu]
Im Falle der Verwendung des Linux Hotplug Projektes wird nun /sbin/hotplug als derartiger Hotplugdaemon über dessen Eintrag in /proc/sys/kernel/hotplug eingehängt. /sbin/hotplug empfängt damit alle Hotplug Ereignisse des Kernels und übernimmt somit die Verantwortung über die weitere
Behandlung des Ereignisses im Userspace.
Im Folgenden wird nun diese von /sbin/hotplug ausgehende weitere Behandlung durch die flexible
Struktur des Linux Hotplug Projekts anhand am Beispiel des Hotpluggings eines USB-Memorysticks
veranschaulicht [Lum04].
1. USB Memorystick wird vom USB-hub Treiber im Kernel erkannt. Folgende Kernel-loggingMeldung kann über /var/log/messages beobachtet werden. Jun 7 23:28:52 localhost kernel: usb
4-1: new high speed USB device using ehci_hcd and address2
2. Das USB-Subsystem im Kernel initiert ein Hotplugereignis. Der Kernel ruft in Folge dessen das
unter /proc/sys/kernel/hotplug eingetragene Userspace Programm auf - also /sbin/hotplug. Dabei wird als Argument der String „usb“ übergeben (da vom USB-Subsystem im Kernel initiiert)
sowie über Umgebungsvariablen das Ereignis detaillierter charakterisiert.
3. /sbin/hotplug multiplext das Ereignis entsprechend dem übergebenen Argument /sbin/hotplug
selbst dient also nur als Multiplexer, wobei es alle Programme im Verzeichnis /etc/hotplug.d/usb
(da usb als Argument übergeben wurde) sowie in /etc/hotplug.d/default (für jedes Subsystem)
welche auf „.hotplug“ enden aufruft. Dabei wird wiederum das Argument von /sbin/hotplug
übergeben und natürlich sämtliche Umgebungsvariablen vererbt. In der Standard hotplug-Installation
wird für unser Beispiel des USB-Memorysticks dabei nur /etc/hotplug.d/default/default.hotplug
ausgeführt, da der Ordner /etc/hotplug.d/usb leer ist.
4. /etc/hotplug.d/default/default.hotplug delegiert den Aufruf an
/etc/hotplug/usb.agent /etc/hotplug.d/default/default.hotplug sucht nun nach entsprechenden agentScripts, welche folgende Pfadform haben /etc/hotplug/*.agent. Im Falle des Arguments usb wird
28
also der USB-Agent namens /etc/hotplug/usb.agent ausgeführt, welchem dann wieder die vererbte Umgebung bereitsteht. Diese drückt sich in den wesentlichen Umgebungsvariablen im
Falle unseres USB-Memorysticks beispielsweise wie folgt aus:
ACTION: add
DEVPATH: /devices/pci0000:00/0000:00:10.3/usb4/4-1/4-1:1.0
DEVICE: /proc/bus/usb/004/003
INTERFACE: 8/6/80
PRODUCT: 41e/4129/1103
TYPE: 0/0/0
5. Der USB-Agent /etc/hotplug/usb.agent wird mit der Vererbten Umgebung aufgerufen Die entscheidenden Umgebungsvariablen für den USB-Agenten sind vor allem ACTION - anhand welchem entschieden wird was zu machen ist - und PRODUCT, INTERFACE und TYPE anhand
welcher entschieden wird um welches Gerät es sich genau handelt und welche nötigen Aktionen
sich dazu ergeben. Dabei ergeben sich folgende Unterschritte:
(a) Nachdem $ACTION add ist werden nötige Kernelmodule geladen. Zu diesem Zweck
wird die entsprechende von den modutils erzeugte Modul-Mappingdatei modules.usbmap
(z.B.: /lib/modules/2.6.10-5-386/modules.usbmap) des Kernels nach passenden Modulen
durchsucht welche dann geladen werden. Dabei enthält jede Zeile von modules.usbmap
ein Modul, welches im Falle der Übereinstimmung der restlichen Attributwerte der Zeile
mit dem Gerät welches unter Betrachtung steht, geladen werden soll. Für unser Beispiel
ergibt sich dabei dass das Kernelmodul usb-storage mit all seinen Abhängigkeiten zu anderen Kernelmodulen geladen werden soll.
(b) Als nächstes wird die Datei /etc/hotplug/usb.handmap, welche das gleiche Fromat wie
modules.usbmap auf Übereinstimmungen für zu ladende Module überprüft. Diese Datei
existiert dabei um Geräte die aus irgendwelchen Gründen nicht von den modutils auf
Kernelmodule gemappt werden über diesen Weg zu laden. Zu beachten ist, dass diese
Datei zum Umfang von hotplug gehört, die vorhin besprochene modules.usbmap jedoch
zu den Kernelmodulen im Zusammenhang mit den modutils.
(c) Als letztes erfolgt durch den USB-Agenten ein ähnliches Laden von Modulen gemäß den
Dateien /etc/hotplug/usb.usermap und allen Dateien namens /etc/hotplug/usb/*.usermap.
An diesen Stellen soll es dem Benutzer ermöglicht werden eigene Mappings für zu ladende Module bzw. zu startende Scripts in das Hotplugging System einzufügen. Dabei
wird bei einer Übereinstimmung und im Falle dass der entsprechende Eintrag kein Kernelmodul bezeichnet das der Übereinstimmung gleichnamige Script in /etc/hotplug/usb
ausgeführt. In unserem Beispiel wird hier keine Übereinstimmung gefunden
6. Die Ausführung kehrt zurück zum Kernel
Es sei hier erwähnt dass die gerade ausgeführte Bearbeitungsreihenfolge die der Ereignisbehandlung für den erkannten USB-Memorystick an dem entsprechenden USB-Hub ist. Im Zuge des Hotpluggings des USB-Memorysticks treten jedoch eine Vielzahl von Ereignissen auf,
welche alle eine entsprechende Behandlung erfahren. So emuliert etwa das Kernelmodul usbstorage einen SCSI Hostadapter und stellt über diesen Umweg den USB-Memorystick als SCSI
Festplatte dar. Dadurch ergibt sich eine Reihe von Folgeereignissen, welche jedoch wiederum
nach dem grundsätzlich gleichen Schema behandelt werden. Letztendlich muss auch noch eine
29
entsprechend benannte Gerätedatei erzeugt werden, damit im Userspace mit dem Gerät interagiert werden kann. Außerdem muss letztlich die emulierte SCSI-Festplatte gemountet werden und eine entsprechende Integration in die Desktopumgebung erfolgen. Für die Benennung,
Erzeugung und Entfernung entsprechender Gerätedateien bzw. Umbenennung von Netzwerkschnittstellen wird nun udev verwendet, welches im Folgenden behandelt werden soll.
udev (Linux configurable dynamic device naming support) Udev wird üblicherweise über ein
Script namens /etc/hotplug.d/default/udev.hotplug in das Hotplug System eingehängt und somit wird
diesem grundsätzlich die Behandlung jedes Hotplug-Ereignisses ermöglicht. Der Ansatz von udev ist
dabei durch den Vergleich von Informationen, welche sysfs sowie das Hotplug System zur Verfügung
stellen, mit vom Benutzer konfigurierten Regeln eine entsprechende flexible Benennungssystematik
für Gerätedateien und Netzwerkschnittstellen bereitzustellen [SuS]. Eine genauere Behandlung des
Konzepts von udev kann [KH03] entnommen werden, wobei insbesondere der Unterschied zu einer kernelbasierten Lösung wie etwa das ältere devfs aufgezeigt wird. Bevor udev nun Gerätedateien
unter /dev erzeugt, liest es alle Dateien in /etc/udev/rules.d mit der Endung .rules in alphabetischer
Reihenfolge ein. Die erste Regel, die zu einem Gerät passt, wird verwendet, auch wenn noch weitere
existieren. Regeln haben dabei die Form: Schlüssel, [Schlüssel, ...] NAME [, SYMLINK] Über die
Schlüssel kann nun die Voraussetzung definiert werden welche gegeben sein muss damit eine Gerätedatei mit dem angegebenen Namen sowie optional ein symbolischer Link zu dieser erzeugt wird.
Die Schlüssel beziehen sich dabei etwa auf den Bustyp oder beliebigen Einträgen in sysfs. Genaueres kann dabei der Manpage von udev entnommen werden. Außerdem ruft udev in ähnlicher Weise
wie hotplug Programme bzw. Scripts in /etc/dev.d/ auf wodurch entsprechende Benachrichtigungen
bei Erzeugung bzw. Entfernung von Gerätedateien ermöglicht werden. Die Aufrufsystematik ist dabei
auf 3 Ebenen gegeben:
/etc/dev.d/DEVNAME/*.dev DEVNAME . . . Name der Gerätedatei/Schnittstelle
/etc/dev.d/SUBSYSTEM/*.dev SUBSYSTEM . . . Subsystem des Hotplug Ereignisses
/etc/dev.d/default/*.dev . . . Behandlungen für alle Ereignisse
Ein Beispiel für ein derartiges Benachrichtigungsprogramm wäre etwa der HAL device name
helper /etc/dev.d/default/hal.dev, über welchen HAL über neue bzw. entfernte Gerätedateien bzw.
umbenannte Netzwerkschnittstellen benachrichtigt wird. Nach obigem Schema ist ersichtlich, dass
dieses Programm für jedes Ereignis mit den entsprechenden Argumenten bzw. Umgebungsvariablen
der Hotplug-Ereignisses aufgerufen wird. Die Intention von HAL besonders im Zusammenhang mit
Hotplugging soll nun als nächstes behandelt werden.
HAL (Hardware Abstraction Layer) Das Konzept von HAL besteht darin detaillierte Metadaten über Geräte zu verwalten und diese Applikationen auf System- und Desktopebene bereitzustellen,
sowie asynchrone Benachrichtigungen über Änderungen in der Hardwarekonfiguration vorzunehmen.
Dabei werden in HAL Geräte als sog. device objects dargestellt, welche eine eindeutige Identifizierung
(UDI) und eine Menge von key/value Paaren haben welche in einen hierarchischen Namensraum eingeteilt sind und auch device properties genannt werden. Außerdem können device objects miteinander
in Beziehung stehen, wodurch insbesondere eine Hierarchische Strukturierung der Geräteabhängigkeiten möglich ist. Eine detaillierte Betrachtung von HAL würde den Rahmen dieser Seminararbeit
sprengen, weshalb an dieser Stelle auf [Zeu] verwiesen sei. Ziel dieses Abschnittes ist es einen Überblick zu geben und vor allem den Zusammenhang mit Hotplugging zu erläutern. Die grundsätzliche
Architektur von HAL wird dazu in Abbildung 2.7 dargestellt.
30
Abbildung 2.7: Architektur HAL [Zeu]
In Abbildung 2.7 als auch im Detail in Abbildung 2.6 ist ersichtlich das sowohl linux-hotplug als
auch udev mit dem HAL daemon verbunden sind. Diese Verbindung erfolgt über den HAL hotplug
helper sowie den HAL device name helper deren Aufruf entsprechend in den hotplugging Ablauf
eingehängt ist (/etc/hotplug.d/default/hal.hotplug und /etc/dev.d/default/hal.dev). Diese beiden Helper
Programme übernehmen im Falle eines Hotplug Ereignisse die entsprechende Benachrichtigung des
HAL daemon über etwaige neue bzw. Entfernte Geräte bzw. neue bzw. Entfernte Gerätedateien oder
Netzwerkschnittstellennamensänderungen.
Wie aus Abbildung 2.7 ersichtlich ist, stellt der HAL daemon die zentrale Instanz in HAL dar.
Der HAL daemon hält nun über eine Datenbank alle dem System bekannten device objects und deren Zusammenhang, wobei er insbesondere für das life cyle management dieser objekte Zuständig ist
- also entsprechend über Änderungen in der Hardwarekonfiguration informiert sein muss um einen
aktuellen Systemzustand repräsentieren zu können. Dazu besitzt der HAL daemon entsprechende
Erkennungs- und Monitoringfähigkeiten für Busse (wie etwa PCI und USB) sowie Geräte und ist
an die asynchrone Benachrichtigung über Hotpluggingereignisse angewiesen welche beispielsweise
durch die Integration in linux-hotplug und udev erfolgen. Über dieses Prinzip ist nun eine abstrakte
Schicht zur Beschreibung der Hardware geschaffen mit welcher eine bidirektionale Kommunikation mit der Anwendungs- und Systemsoftware erfolgt. Anwendungsprogramme kommunizieren dabei
über D-BUS, was im Wesentlichen ein IPC (Interprocess communication) Framework darstellt, mit
dem HAL daemon. Außerdem benachrichtigt (asynchron) der HAL daemon auf diesem Weg Anwendungen über Änderungen in der Hardwarekonfiguration.
Weiter besteht die Möglichkeit zu sog. callouts, was Programmaufrufe in Folge von Änderungen an device objects sind. Diese callouts werden vor allem für Aktionen auf Systemebene verwendet. Beispiele dafür wären etwa das aktualisieren von Netzwerkschnittstellenkonfigurationen oder das
einhängen von Dateisystemen. Wichtige Klienten von HAL sind natürlich besonders die Desktopmanagementsysteme wie etwa GNOME und KDE (Kommunikation über D-BUS). Durch Unterstützung
31
von HAL können diese Systeme beispielsweise deren Volumemanager konsistent halten, was sich z.b.
dadurch zeigt, dass im Falle des Hotpluggings eine USB-Sticks ein entsprechendes Volume-Symbol
am Desktop erscheint und etwa in einem Dateiordner dieses Volume automatisch geöffnet wird. Derartige Aktionen sind jedoch reine Policy-Entscheidungen der Desktopmanagementsysteme.
Eigene Beurteilung des Userspace Hotplugsystem unter Linux
Wie aus dem vorigen Kapitel ersichtlich wurde stellt das Hotplugsystem unter Linux im Userspace
eine sehr komplexe und teilweise unübersichtliche Lösung dar. Die Hauptkritikpunkte welches sich
aus unserer Sicht ergeben werden im Folgenden angegeben:
• Übergang der Exekution vom Kernel in Shellscripts: Linux Hotplug besteht überwiegend aus
Shellscripts. Dies ist einerseits aus Performancesicht bedenklich, da für jedes Hotplugereignis
ein eigener Prozess gestartet werden muss, andererseits aufgrund der unstrukturierten Schnittstelle welche sich aus Positionsparametern und Umgebungsvariablen zusammensetzt.
• Komplex: Insbesonders das Linux Hotplugging Projekt besteht aus sehr vielen Scripts die im
wesentlichen die Informationen über Umgebungsvariablen weiterleiten. Aufgrund dieser Flexibilität kann man leicht den Überblick verlieren. Hier wäre eine unserer Meinung nach eine
kompaktere und einheitlichere Lösung besser.
Positiv sticht aus unserer Sicht HAL heraus, welches eine effiziente Kommunikation über D-BUS
ermöglicht und klar das Prinzip der Abstraktion bei gleichzeitiger Flexibilität verfolgt. An dieser Stelle sei noch erwähnt, dass in aktuellen Distributionen wie etwa SuSe 9.3 bereits die Benachrichtigung
des Userspaces über Hotplugereignisse mittels Netlink-Sockets zu einem Dämonprozess (udevd) erfolgt, wodurch erste Schritte in Richtung Effizienzsteigerung ersichtlich sind. Außerdem sorgt udevd
für eine Bufferung und Serialisierung gemäß einer vom Kernel generierten Sequenznummer sodass
die richtige Reihenfolge der Ereignisse garantiert wird. Udevd kümmert sich neben dem Herstellen
der richtigen Reihenfolge weiters um die Verteilung an udev und linux-hotplug. Ubuntu 5.04 etwa
verwendet ebenfalls udevd, jedoch wird dieser Dämon-Prozess durch das Programm /sbin/udevsend,
welches im Falle eines Hotplugereignisses anstatt /sbin/hotplug aufgerufen wird, über Hotplugereignisse informiert. Die Entwicklung in diesem Bereich ist als sicherlich noch nicht abgeschlossen hat
unserer Meinung nach eine viel versprechende Zukunft.
32
LITERATURVERZEICHNIS
Literaturverzeichnis
[app]
Apple
Developer
Connection,
Device
http://developer.apple.com/devicedrivers/firewire/index.html.
Drivers
FireWire.
[CCC+ 04] Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies, and Toshiba Corporation. Advanced Configuration and Power Interface Specifikation, Revision 3.0 Kapitel 3: ACPI Overview, September 2004. http://www.acpi.info.
[Com98] Compaq Computer Corporation.
PCI Hot Plug Technoligy,
ftp://ftp.compaq.com/pub/supportinformation/papers/ecg0800698.pdf.
Juni
[Com99] Compaq
Computer
Corporation.
PCI
Hot
Plug
noligy
with
Microsoft
Windows
Architecture,
März
ftp://ftp.compaq.com/pub/supportinformation/papers/ECG0710399.pdf.
1998.
Tech1999.
[GG03]
Andew
Grover
and
Intel’s
Mobile
Products
Group.
Modern
System
Power
Management,
Oktober
2003.
http://www.acmqueue.com/modules.php?name=Content&pa=printer_friendly&pid=81&page=1.
[har]
Elektronik-Kompendium. http://www.elektronik-kompendium.de/sites/com/0403311.htm.
[HKC]
Dave Hansen, Mike Kravetz, and Brad Christiansen. Hotplug Memory and the Linux VM.
http://www.finux.org/Reprints/Reprint-Hansen-OLS2004.pdf.
[KH03]
Greg Kroah-Hartman. A Userspace Implementation of devfs, Proceedings of the Linux
Symposium, July 2003. http://www.kroah.com/linux/talks/ols_2003_udev_paper/ReprintKroah-Hartman-OLS2003.pdf.
[lhm04]
Outline of Memory Hotplug, September 2004. http://lhms.sourceforge.net/outline.html.
[lhn04]
Linux Hotplug Node Support, September 2004. http://lhns.sourceforge.net/overview.html.
[lina]
http://wiki.linuxquestions.org/wiki/Hotplug.
[linb]
Linux-Treiber entwicklen. Gerätetreiber für Kernel 2.6 systematisch eingeführt.
http://ezs.kr.hsnr.de/TreiberBuch/html/index.html.
[linc]
Linux-Treiber
entwicklen.
Gerätetreiber
für
Kernel
eingeführt,
Kapitel
4.1.:
Programmierschnittstelle
33
2.6
der
systematisch
Applikation.
[lind]
Linux-Treiber
entwicklen.
Gerätetreiber
für
eingeführt,
Kapitel
5.2.3.
Gerätenummern
Kernel
2.6
systematisch
ersetzen
Major-Nummern.
[line]
Linux-Treiber entwicklen. Gerätetreiber für Kernel 2.6 systematisch eingeführt, Kapitel
7.5.2. Hotplug. http://ezs.kr.hsnr.de/TreiberBuch/html/index.html.
[linf]
8.2. USB-Subsystem. http://ezs.kr.hsnr.de/TreiberBuch/html/index.html.
[ling]
8.3.: Netzwerk-Subsystem. http://ezs.kr.hsnr.de/TreiberBuch/html/index.html.
[Lum04] Chris Lumens.
Dynamic Hardware Configuration,
http://www.bangmoney.org/presentations/hotplug/.
September
2004.
[Mes97] Hans-Peter Messmer. PC Hardwarebuch, chapter 11.5. Addison-Wesley Deutschland, 1997.
Der SystemManagementMode des Pentium http://www.addisionwessley.de/service/Messmer/chap1104.htm.
[MI96a] Microsoft and Intel.
Advanced Power Management (APM) BIOS
Interface
Specification,
Kapitel
1.3
Concepts,
Febrary
1996.
http://www.microsoft.com/whdc/archive/amp_12.mspx.
[MI96b] Microsoft and Intel.
Advanced Power Management (APM) BIOS Interface Specification, Kapitel 3: Advanced Power Management Software Layers, Febrary 1996.
http://www.microsoft.com/whdc/archive/amp_12.mspx.
[Mic01a] Microsoft Corporation.
Removalbe Devices and Windows, December 2001.
http://www.microsoft.com/whdc/system/pnppwr/hotadd/rem-devs.mspx.
[Mic01b] Microsoft Corporation. Windows XP and Surprise Removal of Hardware, December 2001.
http://www.microsoft.com/whdc/system/pnppwr/hotadd/XPrem-devs.mspx.
[Mic03]
Microsoft Corporation.
Static Resource Affinity Table Version 1.2, March 2003.
http://www.microsoft.com/whdc/system/CEC/SRAT.mspx.
[Mic04]
Microsoft Corporation. Hot Add Memory Support in Windows Server 2003, December
2004. http://www.microsoft.com/whdc/system/pnppwr/hotadd/hotaddmem.mspx.
[MT02]
Peter Monadjemi and Eric Tierling. Windows XP Professional - Profiwissen, Konfiguration,
Netzwerke. Markt+Technik Verlag, 2002.
[osd04]
Hotplug CPU Documentation , September 2004. http://lists.osdl.org/pipermail/hotplug_sig/2004December/000097.html.
[Qua04] Jürgen Quade.
Linux-Treiber entwickeln, Gerätetreiber für Kernel 2.6
systematisch
eingeführt.
Kapitel
7.2.:
Das
neue
Gerätemodell,
2004.
[sf1]
Sourceforge
Linux
Hotplugging
hotplug.sourceforge.net/?selected=overview.
34
Projekt.
http://linux-
[sig]
PCI Special Interest Group. http://www.pcisig.com.
[SuS]
SuSE. SuSE 9.3 Administrationshandbuch. Kapitel 19. Dynamische Device Nodes mit
udev.
[usb00]
Universal
Serial
Bus
Revision
2.0
specification,
http://www.usb.org/developers/docs/usb_20_02212005.zip.
Dezember
2000.
[Wef00] Hans-Gerd Wefels.
Lehrgebiet Technische Informatik 1: Der IEEE-1394Bus (FireWire), Fernuniversität Hagen, Januar 2000.
http://www.stud.fernunihagen.de/q3004317/seminar1921/firewire.htm#_Toc473896488.
[wik05a] Wikipedia
Online
Enzyklopädie:
http://de.wikipedia.org/wiki/Firewire.
IEEE
1394/Firewire,
[wik05b] Wikipedia
Online
Enzyklopädie:
http://en.wikipedia.org/wiki/Plug-and-play.
Plug
and
Play,
Mai
2005.
May
2005.
[wik05c] Wikipedia Online Enzyklopädie: USB, Mai 2005. http://de.wikipedia.org/wiki/Usb.
[Zeu]
David Zeuthen. HAL 0.5.2 Specification. http://www.freedesktop.org/Software/hal.
35

ACPI: Power Management und Hot Plugging

Transcrição

Documentos relacionados

ELBCam 1 - ELB ex Geräte Bensheim

DER NEUE ORDERMAN SRP

Installation unter Windows7

Samsung ML-1520

Spezifikation USB RFID EM41xx Reader Typ II

Neuhold Elektronik

Auf Basis seiner langen Erfahrung hat DVS die wichtigsten

USB 2.0 Video Grabber

Datenblatt GENIE MP-HUB

SRP-350 plus schwarz - Multi