Re: RFC: Extension to External Interrupt API


Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Sep 19, 2016 at 08:31:28AM -0700, Andy Ross wrote:
Vinayak Kariappa Chettimada wrote:
I am implementing a "work" (tasklet in Linux terms), a "work", being
a function/routine, is invoked as a direct call i.e. if the caller
is in the same priority as the ISR and the software interrupt (my
"work" group) that would have been offloaded to (if were at another
priority) is enabled. Hence, the need for irq_is_enabled().

In theory, each h/w interrupt can have separate/own bottom-half
"work" group (ISR). Why, to have priority levels for the
bottom-halves.
Yeah, this got some water-cooler attention last week. So it seems
what you're really asking for is an interrupt bottom half framework
for zephyr. So you can have your fiber scheduled alongside the
hardware interrupts when needed.

And (Ben needs to jump in here, I'm no expert) it seems like we have
most of what is needed already in the fiber scheduler. All that I can
see we'd need is:

1. Map the available hardware interrupt priorities to the top N fiber
priorities.

2. Mask off equal and lower interrupt priorities during the execution
of a fiber at those levels. This may be tricky to specify on all
architectures, and may involve some of them running "bottom half"
fibers with interrupts disabled. It might plausibly break some
assumptions in existing code that has an "in an ISR" notion (the
definition of "ISR" gets fuzzy).

3. Arrange to have the exit code for every ISR call _Swap() to
reschedule instead of returning directly to the interrupted task.
This would have some code size cost (maybe a tiny stub to wrap the
user-defined ISRs), though not huge.

But at that point, you don't need to muck with architecture-specific
interrupts to get what you want. You just wake up your work fiber(s)
from your existing ISRs with whatever IPC mechanism you want (give a
semaphore, write a command to a fifo, whatever) and they get scheduled
at the IRQ-scale priority you want.
The thing is that, if we do that, these bottom-half fibers do not behave
like fibers at all. Fibers are not preemptible, except by ISRs, so the
only concurrency you have to be careful of when you write fiber code is
if you touch data that is also touched by ISRs. A data structure can be
shared between fibers without any mutual exclusion, except if a fiber
can sleep while manipulating such data.

If we start having fibers being able to preempt other fibers, this
breaks the model. It doesn't mean that we cannot have something
different than fibers that run at a higher priority than them. At that
point, fibers then have to be careful of data touched by bottom-halves
as well, but that is not much different than ISRs. But I don't think
that bottom halves should be called 'fibers' (or coop threads in the
unified kernel).

That said, I think it would still be a good idea to implement
bottom-halves.

Join devel@lists.zephyrproject.org to automatically receive all group messages.