Interrupts are handled by the kernel, usually in device-drivers. The best place to learn about them is to
look at some of the driver source-code in your kernel.
The Linux Documentation Project (TLDP) has several articles on the subject, including
this relevant chapter of the Module Programming guide.
If you like to read books in the loo
, not just online (that is, I
hope you don't have a computer
there!), then there are many good titles on
O'Reilly Publishing's web-site, such as
this one.
It is very important to understand the
complete relationship of the various parts of the kernel. In DOS, there is no multitasking, no virtual memory. In Linux, you might be sharing the world with eight other CPUs and a thousand active processes. So, the interrupt handling system is logically split into
two parts, sometimes called the "top half" and the "bottom half." (There was, at one time, a mechanism called TH/BH, now generally superseded by
tasklets.) Anyhow, the essential idea is that the hardware interrupt itself (the "top half") is essentially only a
signal that causes the "real" work, in the "bottom half," to be immediately
scheduled. But you also have issues to consider, like what happens if the process that requested the I/O operation has been swapped-out while waiting? What if the user, accidentally or deliberately, specified a memory-address that he does not own, or owns but is not permitted to write to? And the address, of course, is
virtual, not
real.
It's not extraordinarily difficult but it
is tricky. You can often base your work on an existing production driver, copying it and changing only the essential parts of the code.
