<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Interrupt Handlers</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="The Linux Kernel Module Programming Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Interrupt Handlers"
HREF="interrupthandlers.html"><LINK
REL="PREVIOUS"
TITLE="Interrupt Handlers"
HREF="interrupthandlers.html"><LINK
REL="NEXT"
TITLE="Symmetric Multi Processing"
HREF="c1294.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Linux Kernel Module Programming Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="interrupthandlers.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 12. Interrupt Handlers</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="c1294.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN1210"
></A
>12.1. Interrupt Handlers</H1
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1217"
></A
>12.1.1. Interrupt Handlers</H2
><P
>Except for the last chapter, everything we did in the kernel so far we've done as a response to a process asking for
it, either by dealing with a special file, sending an <TT
CLASS="FUNCTION"
>ioctl()</TT
>, or issuing a system call. But the job
of the kernel isn't just to respond to process requests. Another job, which is every bit as important, is to speak to the
hardware connected to the machine.</P
><P
>There are two types of interaction between the CPU and the rest of the computer's hardware. The first type is when
the CPU gives orders to the hardware, the other is when the hardware needs to tell the CPU something. The second, called
interrupts, is much harder to implement because it has to be dealt with when convenient for the hardware, not the CPU.
Hardware devices typically have a very small amount of RAM, and if you don't read their information when available, it is
lost.</P
><P
>Under Linux, hardware interrupts are called IRQ's (<EM
>I</EM
>nterrupt
<EM
>R</EM
>e<EM
>q</EM
>uests)<A
NAME="AEN1226"
HREF="#FTN.AEN1226"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
>. There are two types of IRQ's, short and long. A short IRQ is one which is
expected to take a <EM
>very</EM
> short period of time, during which the rest of the machine will be blocked
and no other interrupts will be handled. A long IRQ is one which can take longer, and during which other interrupts may
occur (but not interrupts from the same device). If at all possible, it's better to declare an interrupt handler to be
long.</P
><P
>When the CPU receives an interrupt, it stops whatever it's doing (unless it's processing a more important interrupt,
in which case it will deal with this one only when the more important one is done), saves certain parameters on the stack
and calls the interrupt handler. This means that certain things are not allowed in the interrupt handler itself, because
the system is in an unknown state. The solution to this problem is for the interrupt handler to do what needs to be done
immediately, usually read something from the hardware or send something to the hardware, and then schedule the handling of
the new information at a later time (this is called the <SPAN
CLASS="QUOTE"
>"bottom half"</SPAN
>) and return. The kernel is then
guaranteed to call the bottom half as soon as possible -- and when it does, everything allowed in kernel modules will be
allowed.</P
><P
>The way to implement this is to call <TT
CLASS="FUNCTION"
>request_irq()</TT
> to get your interrupt handler called when
the relevant IRQ is received (there are 15 of them, plus 1 which is used to cascade the interrupt controllers, on Intel
platforms). This function receives the IRQ number, the name of the function, flags, a name for
<TT
CLASS="FILENAME"
>/proc/interrupts</TT
> and a parameter to pass to the interrupt handler. The flags can include
<TT
CLASS="PARAMETER"
><I
>SA_SHIRQ</I
></TT
> to indicate you're willing to share the IRQ with other interrupt handlers (usually because
a number of hardware devices sit on the same IRQ) and <TT
CLASS="PARAMETER"
><I
>SA_INTERRUPT</I
></TT
> to indicate this is a fast
interrupt. This function will only succeed if there isn't already a handler on this IRQ, or if you're both willing to
share.</P
><P
>Then, from within the interrupt handler, we communicate with the hardware and then use
<TT
CLASS="FUNCTION"
>queue_task_irq()</TT
> with <TT
CLASS="FUNCTION"
>tq_immediate()</TT
> and
<TT
CLASS="FUNCTION"
>mark_bh(BH_IMMEDIATE)</TT
> to schedule the bottom half. The reason we can't use the standard
<TT
CLASS="FUNCTION"
>queue_task</TT
> in version 2.0 is that the interrupt
might happen right in the middle of somebody else's
<TT
CLASS="FUNCTION"
>queue_task</TT
><A
NAME="AEN1263"
HREF="#FTN.AEN1263"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
>. We need <TT
CLASS="FUNCTION"
>mark_bh</TT
> because earlier versions of Linux only had an array of 32
bottom halves, and now one of them (<TT
CLASS="PARAMETER"
><I
>BH_IMMEDIATE</I
></TT
>) is used for the linked list of bottom halves for
drivers which didn't get a bottom half entry assigned to them.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="KEYBOARD"
></A
>12.1.2. Keyboards on the Intel Architecture</H2
><P
>The rest of this chapter is completely Intel specific. If you're not running on an Intel platform, it
will not work. Don't even try to compile the code here.</P
><P
>I had a problem with writing the sample code for this chapter. On one hand, for an example to be useful it has to
run on everybody's computer with meaningful results. On the other hand, the kernel already includes device drivers for
all of the common devices, and those device drivers won't coexist with what I'm going to write. The solution I've found
was to write something for the keyboard interrupt, and disable the regular keyboard interrupt handler first. Since it is
defined as a static symbol in the kernel source files (specifically, <TT
CLASS="FILENAME"
>drivers/char/keyboard.c</TT
>), there
is no way to restore it. Before <TT
CLASS="USERINPUT"
><B
>insmod</B
></TT
>'ing this code, do on another terminal <TT
CLASS="USERINPUT"
><B
>sleep 120
; reboot</B
></TT
> if you value your file system.</P
><P
> This code binds itself to IRQ 1, which is the IRQ of the keyboard controlled under Intel architectures. Then, when
it receives a keyboard interrupt, it reads the keyboard's status (that's the purpose of the
<TT
CLASS="USERINPUT"
><B
>inb(0x64)</B
></TT
>) and the scan code, which is the value returned by the keyboard. Then, as soon as the
kernel thinks it's feasible, it runs <TT
CLASS="FUNCTION"
>got_char</TT
> which gives the code of the key used (the first seven
bits of the scan code) and whether it has been pressed (if the 8th bit is zero) or released (if it's one).</P
><DIV
CLASS="EXAMPLE"
><A
NAME="AEN1291"
></A
><P
><B
>Example 12-1. intrpt.c</B
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>/* intrpt.c - An interrupt handler.
*
* Copyright (C) 2001 by Peter Jay Salzman
*/
/* The necessary header files */
/* Standard in kernel modules */
#include <linux/kernel.h> /* We're doing kernel work */
#include <linux/module.h> /* Specifically, a module */
/* Deal with CONFIG_MODVERSIONS */
#if CONFIG_MODVERSIONS==1
#define MODVERSIONS
#include <linux/modversions.h>
#endif
#include <linux/sched.h>
#include <linux/tqueue.h>
/* We want an interrupt */
#include <linux/interrupt.h>
#include <asm/io.h>
/* In 2.2.3 /usr/include/linux/version.h includes a macro for this, but
* 2.0.35 doesn't - so I add it here if necessary.
*/
#ifndef KERNEL_VERSION
#define KERNEL_VERSION(a,b,c) ((a)*65536+(b)*256+(c))
#endif
/* Bottom Half - this will get called by the kernel as soon as it's safe
* to do everything normally allowed by kernel modules.
*/
static void got_char(void *scancode)
{
printk("Scan Code %x %s.\n",
(int) *((char *) scancode) & 0x7F,
*((char *) scancode) & 0x80 ? "Released" : "Pressed");
}
/* This function services keyboard interrupts. It reads the relevant
* information from the keyboard and then scheduales the bottom half
* to run when the kernel considers it safe.
*/
void irq_handler(int irq, void *dev_id, struct pt_regs *regs)
{
/* This variables are static because they need to be
* accessible (through pointers) to the bottom half routine.
*/
static unsigned char scancode;
static struct tq_struct task = {NULL, 0, got_char, &scancode};
unsigned char status;
/* Read keyboard status */
status = inb(0x64);
scancode = inb(0x60);
/* Scheduale bottom half to run */
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,2,0)
queue_task(&task, &tq_immediate);
#else
queue_task_irq(&task, &tq_immediate);
#endif
mark_bh(IMMEDIATE_BH);
}
/* Initialize the module - register the IRQ handler */
int init_module()
{
/* Since the keyboard handler won't co-exist with another handler,
* such as us, we have to disable it (free its IRQ) before we do
* anything. Since we don't know where it is, there's no way to
* reinstate it later - so the computer will have to be rebooted
* when we're done.
*/
free_irq(1, NULL);
/* Request IRQ 1, the keyboard IRQ, to go to our irq_handler.
* SA_SHIRQ means we're willing to have othe handlers on this IRQ.
* SA_INTERRUPT can be used to make the handler into a fast interrupt.
*/
return request_irq(1, /* The number of the keyboard IRQ on PCs */
irq_handler, /* our handler */
SA_SHIRQ,
"test_keyboard_irq_handler", NULL);
}
/* Cleanup */
void cleanup_module()
{
/* This is only here for completeness. It's totally irrelevant, since
* we don't have a way to restore the normal keyboard interrupt so the
* computer is completely useless and has to be rebooted.
*/
free_irq(1, NULL);
} </PRE
></FONT
></TD
></TR
></TABLE
></DIV
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1226"
HREF="x1210.html#AEN1226"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>This is standard nomencalture on the Intel architecture
where Linux originated.</P
><P
></P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1263"
HREF="x1210.html#AEN1263"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
><TT
CLASS="FUNCTION"
>queue_task_irq</TT
> is protected from this by a global lock
-- in 2.2 there is no <TT
CLASS="FUNCTION"
>queue_task_irq</TT
> and <TT
CLASS="FUNCTION"
>queue_task</TT
> is protected by a
lock.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="interrupthandlers.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="c1294.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Interrupt Handlers</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="interrupthandlers.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Symmetric Multi Processing</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
