This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Q about HAL_INTERRUPT_MASK/UNMASK.
- From: Jonathan Larmour <jlarmour at redhat dot com>
- To: Sergei Organov <osv at javad dot ru>
- Cc: ecos-discuss at sourceware dot cygnus dot com
- Date: Wed, 23 Jan 2002 20:01:43 +0000
- Subject: Re: [ECOS] Q about HAL_INTERRUPT_MASK/UNMASK.
- Organization: Red Hat UK Ltd.
- References: <873d0z7fxx.fsf@osv.javad.ru>
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