This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Q about HAL_INTERRUPT_MASK/UNMASK.


Sergei Organov wrote:
> 
> Hello,
> 
> Is it required by the HAL interface that implementation of HAL_INTERRUPT_MASK
> and HAL_INTERRUPT_UNMASK be reentrant?
> 
> Consider simple interrupt controller having an interrupt enable register (IER)
> where single bit is dedicated for every interrupt source.  Suppose also that
> processor doesn't have atomic "set bit"/"clear bit" instructions.
> Implementation of mentioned macros for such an architecture wold look like
> this:
> 
> 1. Read IER to a temporary;
> 2. Set/Clear bit in the temporary;
> 3. Write temporary back to IER;
> 
> Once this sequence is interrupted between (1) and (3) and interrupting code
> also invokes one of these macros we are in trouble.
> 
> So the question is: is it required to disable/enable processor interrupts at
> the beginning/end of these macros when implementing HAL for such architecture?

This sparked off an internal discussion that's taken till now to resolve.
The solution that I've now implemented internally is that the kernel/driver
API layer will disable interrupts (although new
cyg_interrupt_mask_intunsafe() functions are available for the old
behaviour).

So the HAL macros should not worry about interrupt safety - apps should be
using higher level APIs (unless they have reason not to, in which case the
onus is on them). This has even been documented as well!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]