Hi Dmitry,

Dmitry Adamushko wrote:
> Hi Jan,
> 
> let's make yet another revision of the bits :
> 
> new XN_ISR_HANDLED  == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
> 
> ok.
> 
> new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
> 
> ok.
> 
> new XN_ISR_PROPAGATE == XN_ISR_CHAINED
> 
> ok.
> 

Just to make sure that you understand my weird ideas: each of the three
new XN_ISR_xxx above should be encoded with an individual bit

> new XN_ISR_NOINT == ?
> 
> does it suppose the interrupt line to be .end-ed (enabled) and irq not to be
> propagated? Should be so, I guess, if it's different from 5). Then nucleus
> ignores implicit IRQ enable for 5) as well as for 3).
> 
> Do we really need that NOINT then, as it seems to be the same as ~HANDLED?
> 
> or NOINT == 0 and then it's a scalar value, not a bit.
> 
> So one may consider HANDLED == 1 and NOINT == 0 as really scalar values
> 
> and
> 
> NOENABLE and PROPAGATE as additional bits (used only if needed).
> 

My idea is to urge the user specifying one of the base return types
(HANDLED or NOINT) + any of the two additional bits (NOENABLE and
PROPAGATE).

For correct drivers NOINT could be 0 indeed, but to check that the user
picked a new constant we may want to set NOINT != 0. With the old API
"return 0" expressed HANDLED + ~ENABLE for the old API. With the new one
the user signals no interest and the nucleus may raise a warning that a
spurious IRQ occurred. So I would add a debug bit for NOINT here to
optionally (on OPT_XENO_DEBUG) detect old-style usage (return 0).
Moreover, we gain freedom to move bits in the future when every state is
encoded via constants. Or am I too paranoid here?

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to