On 21/07/2021 20:10, Gedare Bloom wrote:
One more thing, should we specifically say "on_processor" or
something, to make it clear what this means? When I first read the
function name, I thought it is "cause on a condition" so I was
confused.
Another thought with this "cause_on" directive, shoul
On Wed, Jul 21, 2021 at 11:46 AM Gedare Bloom wrote:
>
> On Wed, Jul 21, 2021 at 11:43 AM Gedare Bloom wrote:
> >
> > Before we bake this into the API forever, I want to ask if "cause" is
> > the right word to use here? Often, "interrupt cause" is thought of as
> > a noun to mean what caused the
On 21/07/2021 19:43, Gedare Bloom wrote:
Before we bake this into the API forever, I want to ask if "cause" is
the right word to use here? Often, "interrupt cause" is thought of as
a noun to mean what caused the interrupt, while the verb is usually
"raise" or post, trigger, etc. Because "cause" i
On Wed, Jul 21, 2021 at 11:43 AM Gedare Bloom wrote:
>
> Before we bake this into the API forever, I want to ask if "cause" is
> the right word to use here? Often, "interrupt cause" is thought of as
> a noun to mean what caused the interrupt, while the verb is usually
> "raise" or post, trigger, e
Before we bake this into the API forever, I want to ask if "cause" is
the right word to use here? Often, "interrupt cause" is thought of as
a noun to mean what caused the interrupt, while the verb is usually
"raise" or post, trigger, etc. Because "cause" is both a noun and a
verb that mean somethin
Document the currently not implemented rtems_interrupt_cause() and
rtems_interrupt_clear().
Update #3269.
---
cpukit/include/rtems/rtems/intr.h | 162 +++---
1 file changed, 125 insertions(+), 37 deletions(-)
diff --git a/cpukit/include/rtems/rtems/intr.h
b/cpukit/includ
