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
signature.asc
Description: OpenPGP digital signature
