Teil 5 - Interrupts — Änderungen 7126 → 7369

Zeile 91: Zeile 91:
  
 
==Nützliche Interrupthandler==
 
==Nützliche Interrupthandler==
−
Jetzt fehlt nur noch die eigentliche Funktion, die aufgerufen werden soll, wenn ein Interrupt auftritt. Meistens möchte man nur einen Handler für alle Interrupts zusammen haben. Ein gemeinsamer Teil soll den Prozessorzustand sichern und der eigentliche Handler soll nur noch ungefähr so aussehen:
+
Jetzt fehlt nur noch die eigentliche Funktion, die aufgerufen werden soll, wenn ein Interrupt auftritt. Meistens möchte man nur einen einzigen Handler für alle Interrupts zusammen haben, der allerdings die Interruptnummer (und den sonstigen Prozessorzustand beim Auftreten des Interrupts) als Parameter übergeben bekommt.
 +
 
 +
Ein vorgeschalteter Teil soll den Prozessorzustand sichern und der eigentliche Handler soll nur noch ungefähr so aussehen:
  
 
<c>void handle_interrupt(struct cpu_state* cpu)
 
<c>void handle_interrupt(struct cpu_state* cpu)
 
{
 
{
 
     if (cpu->intr <= 0x1f) {
 
     if (cpu->intr <= 0x1f) {
−
         kprintf("Exception %d, Kernel angehalten!\n", interrupt);
+
         kprintf("Exception %d, Kernel angehalten!\n", cpu->intr);
  
 
         // Hier den CPU-Zustand ausgeben
 
         // Hier den CPU-Zustand ausgeben
Zeile 208: Zeile 210:
 
     uint32_t  ss;
 
     uint32_t  ss;
 
};</c>
 
};</c>
 +
 +
Nachdem die Handler für die einzelnen Interrupts nun fertig geschrieben sind, müssen sie (falls noch nicht geschehen) natürlich noch in die IDT eingetragen werden, damit sie beim Auftreten eines Interrupts angesprungen werden. Andernfalls würde der Code nie ausgeführt werden.
  
 
Eine geeignete Implementierung für Exceptions ist die oben schon vorgeschlagene Fehlermeldung mit anschließendem Anhalten des Systems (später könnte man das aktuell ausgeführte Programm beenden, aber wir haben so etwas ja noch nicht). Für Hardware-Interrupts muss zumindest ein EOI (End of Interrupt) an den PIC gesendet werden, damit der Interrupt gleich beim nächsten Mal wieder gemeldet wird und nicht noch vom letzten Aufruf blockiert ist:
 
Eine geeignete Implementierung für Exceptions ist die oben schon vorgeschlagene Fehlermeldung mit anschließendem Anhalten des Systems (später könnte man das aktuell ausgeführte Programm beenden, aber wir haben so etwas ja noch nicht). Für Hardware-Interrupts muss zumindest ein EOI (End of Interrupt) an den PIC gesendet werden, damit der Interrupt gleich beim nächsten Mal wieder gemeldet wird und nicht noch vom letzten Aufruf blockiert ist: