OAL ISR or Installable ISR

Sometimes, when someone needs to handle the interrupt for their device driver in an ISR (because using an IST has too much latency or because the interrupt is shared) they will decide to use the OAL's ISR instead of creating an Installable ISR for their driver. In general, using the OAL ISR for your ISR is a bad idea, as it unnecessarily couples the OAL and your particular hardware platform.

The following are examples of Interrupts that normally will be handled in the OAL ISR:

1. System Timer for the SYSINTR_RESCHED.
2. Interrupt for on-chip RTC Driver (as it's driver resides in the OAL.)
3. ISR for Profiler.

Other than the three(3) instances above, we should never really be putting ISR for device drivers in the OALs ISR routine. In fact, if you look at the 3 items above, they all are for components or modules that exist within the OAL itself, not at the Windows CE Kernel or User-Level driver level.

Note: There are likely more instances than the three(3) listed above, but the instances above should be the most common instances of drivers that should have their ISRs included in the OAL.

For drivers such as Ethernet MACs, Serial Ports and LCD Controllers, they should either be using an Installable ISR or simply just an IST. They should never be putting themselves in as an OAL ISR.

Pros of OAL ISR over Installable ISR:

1. ISR gets called slightly faster than Installable ISR.

Cons of OAL ISR over Installable ISR:

1. Driver becomes non-portable. OAL ISR needs to be modified for EVERY platform that the driver must run on.
2. OAL becomes non-portable. OAL becomes tied to hardware platform making it desirable to have one OAL for each hardware platform, or forces the developer to use ifdef's to select hardware platform against OAL.
3. Harder to upgrade driver without replacing entire OS.