PATH
Hardware interrupt level execution happens as a direct result of a hardware interrupt request. To insure maximum system performance, hardware interrupt handlers perform only those actions that must be synchronized with the external device that caused the interrupt and then queue a secondary interrupt handler to perform the remainder of the work associated with the interruption. Hardware interrupt handlers must operate within the restrictions of the interrupt execution model by not causing page faults and by using a limited set of operating-system services. Those services available to hardware interrupt handlers are listed in Table 11-2.
Secondary interrupt level is similar to the deferred task concept in previous versions of Mac OS; conceptually, it exists between the hardware interrupt level and the application level. A secondary interrupt queue is filled with requests to execute subroutines that are posted for execution by hardware interrupt handlers. These handlers need to perform certain actions, but choose to defer the execution of the actions in the interest of minimizing hardware interrupt level execution. The execution of secondary interrupt handlers is serialized. For synchronization purposes, noninterrupt level execution may also post secondary interrupt handlers for execution; they are processed synchronously from the prospective of noninterrupt level but are serialized with all other secondary interrupt handlers.
Like hardware interrupt handlers, secondary interrupt handlers must also operate within the restrictions of the interrupt execution model by not causing page faults and by using a limited set of operating-system services. Those services available to secondary interrupt handlers are listed in Table 11-2.
The execution of secondary interrupt handlers may be interrupted by hardware interrupts.
When writing device drivers that handle hardware interrupts, it is important to balance the amount of processing done within the hardware and secondary interrupt handlers with that done by the driver's tasks at noninterrupt level. The driver writer should make every effort to shift processing time from hardware interrupt level to secondary interrupt level and from secondary interrupt level to the driver's job of supporting its device. Doing this allows the system to be tuned so that the driver does not seize an undue amount of processing time from applications and other drivers.