Requesting the IRQ
After detection, the 36 routine must request any needed interrupt or DMA channels from the kernel. There are 16 interrupt channels, labeled IRQ~0 through IRQ~15. The kernel provides two methods for setting up an IRQ handler: 37 and 38. The 39 function takes two parameters, the IRQ number and a pointer to the handler routine. It then sets up a default 40 structure and calls 41. The code for the 43 function is shown in Figure~#figrequestirq#1301>. I will limit my discussion to the more general 44 function.

#figure1302#
Figure: The <#1304#> request_irq()<#1304#> Function

The declaration for the 46 function is verbatim20 where the first parameter, 47, is the number of the IRQ that is being requested, and the second parameter, 48, is a structure with the definition shown in Figure~#figsigaction#1312>.

#figure1313#
Figure: The <#1315#> sigaction<#1315#> Structure

In this structure, 50 should point to your interrupt handler routine, which should have a definition similar to the following: verbatim22 where 51 will be the number of the IRQ which caused the interrupt handler routine to be invoked. The 52 variable is used as an internal flag by the 53 routine. Traditionally, this variable is set to zero prior to calling 54. The 55 variable can be set to zero or to 56. If zero is selected, the interrupt handler will run with other interrupts enabled, and will return via the signal-handling return functions. This option is recommended for relatively slow IRQs, such as those associated with the keyboard and timer interrupts. If 57 is selected, the handler will be called with interrupts disabled and return will avoid the signal-handling return functions. 58 selects ``fast'' IRQ handler invocation routines, and is recommended for interrupt driven hard disk routines. The interrupt handler should turn interrupts on as soon as possible, however, so that other interrupts can be processed. The 59 variable is not currently used, and is traditionally set to 60. The 61 and 62 functions will return zero if the IRQ was successfully assigned to the specified interrupt handler routine. Non-zero result codes may be interpreted as follows:

#dispitems1321#

The kernel uses an Intel ``interrupt gate'' to set up IRQ handler routines requested via the 65 function. The Intel i486 manual [#i486manual##1#, p.~9-11,] explains the interrupt gate as follows:

Interrupts using... interrupt gates... cause the TF flag [trap flag] to be cleared after its current value is saved on the stack as part of the saved contents of the EFLAGS register. In so doing, the processor prevents instruction tracing from affecting interrupt response. A subsequent IRET [interrupt return] instruction restores the TF flag to the value in the saved contents of the EFLAGS register on the stack. ...<#1327#><#1327#> An interrupt which uses an interrupt gate clears the IF flag [interrupt-enable flag], which prevents other interrupts from interfering with the current interrupt handler. A subsequent IRET instruction restores the IF flag to the value in the saved contents of the EFLAGS register on the stack.