Re: [ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[Nick Garnett <nickg@ecoscentric.com>]

"Mike Sweeney" <msweeney77@gmail.com> writes:

> I am a little confused about what HAL_INTERRUPT_ACKNOWLEDGE is
> intended to do. The reference manual for eCos says that it is used if
> the interrupt controller requires you to acknowledge an interrupt. The
> reason I am confused is that an interrupt service routine for a device
> may need to clear a status flag in a peripheral status register even
> if there is no interrupt controller. Is the intent that each interrupt
> service routine handle this clearing of the flag in the peripheral
> status register on its own, in addition to calling
> HAL_INTERRUPT_ACKNOWLEDGE for handling anything that has to do with
> the interrupt controller? It seems this is the case, but why is there
> this special function in the HAL for handling the interrupt controller
> acknowledgement? Why isn't this just handled directly by each device's
> interrupt service routine without going through this interface?
> 
> The hal_clock_reset() function makes it quite clear to me that each
> ISR handles any status flags itself, because this is the only way the
> ISR for the real time clock could be made generic as it is in the
> kernel by calling hal_clock_reset() in addition to calling
> HAL_INTERRUPT_ACKNOWLEDGE().

There are several reasons for this:

1. Abstraction. The author of a device driver should only need to
   concern himself with the details of the device, not with the
   details of the interrupt controller too. Acknowledgement is
   abstracted for the same reason masking and configuring the
   interrupts are also abstracted; the same reason we have HALs, a
   kernel, libraries and subsystems: division of responsibility into
   well defined layers.

2. Maintenance. If the way the interrupt controller is used needs to
   be changed, or a bug is found, it need only be changed in one
   place, and one doesn't have to search through all the device
   drivers for random bits of code.

3. Portability. Some device drivers are portable: many of the ethernet
   drivers, 16550 serial driver, CAN, USB etc. These drivers cannot
   contain code for all the possible platforms they may run on;
   platform-specific operations need to be handled in a portable way.

-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss