Hardware Abstraction Layer

Aus Lowlevel
Wechseln zu:Navigation, Suche

Die HAL (Hardware Abstraction Layer) bezeichnet eine Softwareschicht, die zwischen der Hardware und dem Betriebssystemkernel liegt. Sie hat die Aufgabe, hardwarespezifische Funktionen auszulagern, um eine spätere Portierung zu erleichtern, da im besten Fall nur die HAL angepasst werden muss. Die verbreitesten Betriebsysteme haben eine HAL.

Aufgaben

Die HAL beinhaltet somit folgende Aufgaben, wobei zu beachten ist, dass das nur mögliche Teile einer HAL sind. Was genau der HAL macht hängt sehr von der Struktur des OS ab. In gewissen Grenzen ist es auch eine Sache der persönlichen/subjektiven Definition ob bestimmte Code-Fragmente vom OS Teil des HAL sind oder einer anderen Komponente zugeordnet werden.

I/O-Ports

Um I/O-Ports zu verwalten könnten Funktionen zum Allozieren und Freigeben von I/O-Ports zur Verfügung gestellt werden, falls die Architektur (wie z. B. x86 und x86-64) I/O-Ports zur Verfügung stellt. Außerdem werden Funktionen benötigt um auf die I/O-Ports zuzugreifen.

Memory-mapped I/O

Zusätzlich zu den I/O-Ports – oft auch anstelle der I/O-Ports – wird von der Architektur an bestimmmten Speicherbereichen nicht normaler RAM eingeblendet, sondern Register von Hardwarekomponenten. Es kann deshalb sinnvoll sein, Funktionen zum Allozieren, Freigeben und zum Zugriff auf solche Speicherbereiche vorzusehen. Dabei ist zu beachten, dass in C und C++ der type-qualifier volatile verwendet werden sollte, um auf solche Speicherbereiche zuzugreifen.

Interruptverwaltung

Damit die angeschlossene Hardware einem Treiber irgendwelche Ereignisse signalisieren kann, stellt die Architektur meist Interrupts bzw. genauer IRQs zur Verfügung. Um Interrupts zu verwenden ist zum einen meist eine Tabelle mit den Adressen von ISRs (Interrupt Service Routines; bei x86/x86-64 ist diese Tabelle die IDT im Protected- und Long-Mode) notwendig. Zum anderen werden die ISR-Stubs von der HAL bereitgestellt, da diese meist in Assembler geschrieben und damit sehr architekturspezifisch sind. IRQs werden meist über eine spezielle Hardwarekomponente – bei x86 bzw. x86-64 ist das die PIC oder in neueren Systemen auch die I/O APIC (im Zusammenspiel mit der Local APIC dann) – auf Interrupts abgebildet. Daher ist ein Treiber für diese Hardwarekomponente auch Teil der HAL.

Nach außen werden dann Funktionen zum Registrieren von Handlern für Interrupts bzw. IRQs bereitgestellt. Beim Auftreten des entsprechenden Interrupts werden diese Handler dann von den ISR-Stubs der HAL aufgerufen.

Syscallverwaltung

Damit Anwendungen Kernelfunktionalität nutzen können werden vom Kernel Syscalls zur Verfügung gestellt. Da die Art, wie diese Syscalls vom Usermode aus aufgerufen werden, architekturspezifisch ist – meist über Interrupts oder Spezialinstruktionen wie sysenter oder syscall – sind Stubs, welche die Implementierung der Syscalls aufrufen, meist Teil der HAL.

Speicherverwaltung

Auch Teile der physischen Speicherverwaltung (z. B. die Größe der Pages) und die komplette virtuellen Speicherverwaltung sind architekturspezifisch und damit Teil der HAL.

Bei x86 bzw. x86-64 fällt hierunter auch die GDT.

Scheduling

Der Scheduler hat unter anderem die Aufgabe den Kontext zu wechseln. Dabei müssen Register gesichert und wiederhergestellt werden und außerdem der virtuelle Adressraum gewechselt werden, d. h. dieser Teil des Schedulers ist extrem abhängig von der Architektur und gehört somit auch zur HAL. Außerdem muss der Scheduler von einem Timer – bei x86/x86-64 die PIT, der RTC, die Local APIC-Timer oder der HPET – aufgerufen werden, d. h. der Treiber für diesen Timer könnte auch Teil der HAL sein.

Plug-and-Play

Das OS muss oft erst die im System vorhandenen Geräte alle finden und die benutzten (Speicher-/IO-/Interupt-)Ressourcen ermitteln oder selber vergeben. Dazu werden für moderne Hardware-Komponenten üblicherweise die Plug-and-Play-Mechanismen des betreffenden Busses (über den das Gerät dem System zugänglich ist) benutzt. Bei z.B. PCI-Geräten wird dazu der PCI-Config-Space benutzt und damit nicht alle Treiber selber direkt darauf zugreifen müssen bietet der OS-Kernel üblicherweise passende Funktionen an welche wiederum als Teil des HAL gezählt werden können.