Re: [ECOS] Q about HAL_INTERRUPT_MASK/UNMASK.

[Sergei Organov <osv at javad dot ru>]

Jonathan Larmour <jlarmour@redhat.com> writes:
> 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).

Thanks for explanation. I wonder what's the rationale behind such decision?

For me it seems more natural and effective to require HAL macros to be
interrupt-safe, because the way to achieve interrupt safety is obviously
hardware dependent. There even could be architectures where this doesn't
require any additional actions to be made. For such architectures
disabling/enabling interrupts in cyg_interrupt_mask() will be just an
overhead. Even worse if on this architecture disabling/enabling global
interrupts is costly or masking/unmasking of individual interrupts is lengthy
(though to tell the truth I don't know any architecture where this would be
the case). Also, an example already exists when interrupts safety is explicitly
required for HAL macros by the HAL API specification. I mean context switch
macros.

As you've decided to implement it differently, there should be a reason, but I
don't see one. Could you please enlighten me?

> 
> 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!

I know. But currently it seems that these HAL macros are just directly mapped
to corresponding user API routines and documentation doesn't mention interrupt 
safety neither for user API routines nor for HAL API.

BR,
Sergei.