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,
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.