Interrupts are how hardware gets software's attention. Here's how they work.

IRQ Allocation

A snapshot of interrupts already in use on
the system is stored in the /proc directory. The
$cat /proc/interrupt command displays the data
related to the interrupts. The
following output was displayed on my machine:

The first column is the IRQ line (vector ranges from 32–47), and the next
column is the number of times the interrupts are delivered in the CPU after
booting the system. The third column is related to the
PIC, and the last column is the list of the device
names that have registered handlers for the corresponding interrupt.

The simplest way to load a device driver
dynamically is first to find the unused IRQ line in the system. A request_irq function
is used to allocate a specified IRQ line number for a device. The syntax
for the request_irq follows and is declared in linux/sched.h:

unsigned int irq: interrupt number, which we want to request from the system.

void (*handler) (int, void *, struct pt_regs *): whenever an interrupt
is generated, we have to write ISRs to handle the interrupt;
otherwise, the processor simply acknowledges it and does nothing else
for that interrupt. This argument is the pointer to the handler function.
The syntax for the handler function is:

void
handler (int irq, void *dev_id,
struct pt_regs *regs);

The first argument is the IRQ number, which we
already have mentioned in the request_irq function.
The second argument is a device identifier,
using major and minor numbers to identify which
device is in charge of the current interrupt
event. The third argument is used to save
the process' context in the kernel stack before
the processor starts executing the interrupt
handler function. This structure is used when
the system resumes the execution of the earlier
process. Normally, device driver writers need not
worry about this argument.

unsigned long flags: the flags variable is used for
interrupt management. The SA_INTERRUPT flag is set
for fast interrupt handler, and it disables all the
maskable interrupt. SA_SHIRQ is set when we want to
share the irq with more than one device, SA_PROBE
is set if we are interested in probing a hardware
device using the IRQ line, and SA_RANDOM is used to seed
the kernel random number generator. For more details of
this flag, see /usr/src/linux/drivers/char/random.c.

constant char *device: a device name that holds the IRQ.

void *dev_id: the device identifier—it's a pointer to the device
structure.
When the interrupt is shared, this field points to the particular device.

The request_irq function returns 0 on success and -EBUSY when the
allocation has failed. EBUSY is the error number of 16, which is
described in the /usr/src/linux/include/asm/errno.h file. The free_irq
function releases the IRQ number from the device. The syntax for
this function is:

free_irq (unsigned int irq, void *dev_id);

The explanation for the arguments is the same as above.

An ISR is invoked whenever an interrupt
occurs. The operations to be performed on the
cause of the interrupt are described in the
ISR. The kernel maintains a table in memory, which
contains the addresses of the interrupt routines
(interrupt vectors). When an interrupt occurs,
the processor checks the address of the ISR in the
interrupt vector table and then executes. The task of
the ISR is to react to the device according to the
nature of the interrupt, such as read or write data. Typically, the ISR
wakes up sleeping processes
on the device if the interrupt signals
the event for which they are waiting.

The amount of time the processor takes to respond to
an interrupt is called interrupt latency. Interrupt
latency is composed of hardware propagation time,
register saving time and software propagation time.
Interrupt latency should be minimal to improve
the system's performance; for this reason, the ISR should
be short and disable interrupts only for a brief
time. Other
interrupts can occur while interrupts are disabled, but the processor does not
allow them until interrupts are re-enabled. If more
than one interrupt is blocked, the processor
allows them in priority order when it is ready
for interrupt service.

Device driver developers should disable
interrupts in driver code only when
necessary, because the system does not update
the system timers, transfer network packets to and
from buffers and so on during the interrupt disabling.
Driver developers should write ISRs
to release the processor for other tasks.
In real-world scenarios, however, ISRs handle lengthy tasks. In such
situations, the ISR
can do only the time-critical communication with
the hardware to disable the interrupt and use
the tasklet to perform most of the actual data
transfer processing. The tasklet is
the advanced feature in the latest Linux kernel
that does certain operations related to the
interrupt during safe times. The tasklet is the
software interrupt, and it can be interrupted by
other interrupts. The internals of the interrupts
have been explained in detail by Bovet and Cesati (see the on-line Resources),
and the implementation of the interrupts in
device driver perspective is presented by Rubini and
Corbet (see Resources).

Thank you very much for your detail information about computer. Kepp it up.Please can give the detail answers of these questions?
1) what does LOC and MIS mean?
2) why so many devices for the some IRQ?
3) is it possible to redefine a better allocation of IRQs? or is that irrelevant?
4) why the same device in different IRQs?