Kernel Korner - Dynamic Interrupt Request Allocation for Device Drivers

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

Any kernel module includes a device driver that can be loaded with the existing kernel, even when the system is running. I explain the basic dynamic IRQ allocation procedure in a simple module shown in Listing 1. The following simple character device driver code describes the dynamic allocation of an IRQ line for a device named OurDevice. When you insert the module, the init_module function is executed. If it is allocated successfully, an unused major number and register for the given IRQ number for the device and the corresponding printk message then is printed. From here, we could check the IRQ allocation in the /proc directory. The given IRQ is released at the time the module is removed. The best place to register an IRQ number is an open entry point of a driver code, which subsequently frees the IRQ in a release function.

The my_module.c file is compiled with the 2.6.0-0.test2.1.29 kernel. The kernel-2.6.0-0.test2.1.30.i586.rpm was downloaded along with all the dependent RPMs and installed. The RPM was downloaded from people.redhat.com/arjanv/2.5/RPMS.kernel, and the device driver program was compiled as follows:

gcc -Wall -O3 -finline-functions \
-Wstrict-prototypes -falign-functions=4 \
-I/lib/modules/2.6.0-0.test2.1.29/build/include \
-I/lib/modules/2.6.0-0.test2.1.29/build/include/
↪asm/mach-default
-I./include -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB \
-DKBUILD_MODNAME=my_module -c my_module.c -o \
my_module.o

After inserting my_module.o, if the major number and the IRQ allocation for the device are successful, the corresponding printk statement output can be seen. If the IRQ number already is in use by another device, the kernel unregisters the device and releases the major number. The $cat /proc/interrupt command displays the following output:

           CPU0
  0:   82887219          XT-PIC  timer
  1:        122          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  OurDevice
  8:          1          XT-PIC  rtc
 10:     154769          XT-PIC  eth0
 12:        100          XT-PIC  i8042
 14:      21636          XT-PIC  ide0
 15:         18          XT-PIC  ide1
NMI:          0
ERR:          0

An entry of OurDevice along with the IRQ line can be seen in the output. When we remove the module, the kernel frees the IRQ number, unregisters the device and releases the major number.

Conclusion

Hopefully, this article makes clear the fundamental concepts of interrupts and the interrupt handling routine. The discussion of the request_irq and free_irq function is useful when we use these concepts in device drivers. The dynamic IRQ allocation procedure has been explained with the simple character device driver code.

Acknowledgements

C. Surest is acknowledged for his help during the preparation of this article.

Resources for this article: /article/8064.

Dr B. Thangaraju received a PhD in Physics and worked as a research associate for five years at the Indian Institute of Science, India. He is presently working as a tech lead in the Embedded Systems Focus Group at Talent Transformation, Wipro Technologies, India. He works in the areas of Linux internals, the Linux kernel, Linux device drivers and embedded and real-time Linux. He can be reached at bt_raju@vsnl.net.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

interrupt requests

jhude's picture

can i just ask what are the different interrupt requests used in programming assembly language?

understanding IRQs

jmnsilva's picture

My output:

~> cat /proc/interrupts
CPU0
0: 8731569 XT-PIC timer
1: 267 XT-PIC i8042
2: 0 XT-PIC cascade
4: 52894 XT-PIC serial
8: 2 XT-PIC rtc
9: 0 XT-PIC acpi
10: 32009 XT-PIC eth1, ohci_hcd, ohci_hcd, eth0, SiS SI7012
11: 0 XT-PIC ehci_hcd
12: 100465 XT-PIC i8042
14: 40665 XT-PIC ide0
15: 74294 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0

poses me some 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?

Do this questions have simple answers?

Thanks

Thanks for your help.

Mulugeta's picture

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?

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix