Interrupts

• 1.2 of the book.
• Hardware watches for "things" out of the ordinary to occur
  • Bad things, like divide by 0
  • Planned things like the debugger wants you to stop
  • Software things like a buffer on a device is available.
  • And other things.
  • See The wikipedia article on the common interrupt events.
• As you can see, some of these are maskable and some are unmaskable
  • maskable interrupts can be blocked in critical sections of the code.
• A simple use of interrupts is for dealing with devices.
  1. The device driver in the kernel transfers the correct data, via the bus, to the device.
     • Think address to read and command to make the device read.
  2. The device performs the action
  3. The device writes data to a buffer for the OS to read
  4. Then the device sends an interrupt to the kernel so it knows that the data is ready.
• When the CPU receives the interrupt
  • It stops what it was doing and handles the request.
  • The request is processed
  • The CPU returns to the current operation.
  • 
• This process minimizes main program interruption.
  • Compare the is to polling
  • The kernel constantly checks the devices to see if they have finished anything!
• The part of the kernel that handles the interrupt is the interrupt service routine.
  • This could be a generic routine that looks at the interrupt and calls a specialized routine
    • But there is a need to be fast.
    • We have many interrupts.
    • watch -n0.1 cat /proc/interrupts
      • watch does a process over and over
      • -n0.1 means run every .1 second
      • cat is a program that shows the contents of a file to the screen.
    • Interestingly enough, wait it's self will use a timer.
      • Which will cause an interrupt every .1 second.
  • So we need as fast a mechanism as possible
  • An interrupt table, or vector.
    • Hard coded in the kernel
    • At each interrupt number, there is an address of code to handle the interrupt. (an interrupt service routine)
    • Saves the state if necessary
    • Handles the interrupt
    • Restores the state.
• In practice
  • There is a buffer called the interrupt-request line
  • The CPU examines this after every F-E-D cycle
  • When this is high, the CPU reads the number and calls the Interrupt handler routine.
    • jmp InterruptVector[interrupt number]
  • At a higher level we say
    • The device controller raises the interrupt
    • The CPU catches the interrupt
    • And the CPU dispatches the interrupt
    • Then the interrupt handler clears the interrupt.
• There are several problem here
  • We might have multiple interrupts occur simultaneously or nearly so.
  • We might have different levels of severity (hardware fault vs new packet arrives)
• To handle this, interrupt control hardware is implemented.
  • Two separate lines, one for maskable and one for non-maskable interrupts.
  • Since there may be may devices that give the same interrupt, a list of handlers may be present
    • They are called one by one until the proper one is found.
  • A priority is assigned to make sure important interrupts are handled first.
• In the intel chip, this is accomplished through the Programmable Interrupt controller or PIC
  • (linux-kernel-labs.github.io).
  • The NMI line is for non maskable interrupts
    • These are most likely the ones that we can't delay
  • The inter line is for maskable interrupts.
    • These, as the picture indicates, are probably I/O interrupts,
    • And thus they can be delayed.
  • The PIC will prioritize the low level interrupts.
  • These can be built to share inturrupts over multiple cpus.
• There is much more to this, if the book comes back, we will to.