Maybe we should preserve that property then. It also looks like __attribute__((interrupt)) isn't common to all arches. Maybe we need something like: void my_isr(void) { IRQ_HEADER(); <service the inte

I think this would be something desirable across arches yes. It would essentially put the ISR directly in the vector table. I imagine the IRQ_CONNECT_DIRECT() feature would have the following characte

Yeah it's probably a dealbreaker. In C you can take the address of some stack variable and pass it to another function, stack references seem to really need to be on the data segment. Oh well. I think

Disregard, this landed directly in my inbox, we're actually talking about kernel LIFOs. We could add checking to LIFOs, but this adds additional overhead. For LIFO use-cases where we always know how d

This is cool, I think we should implement this for ARM targets. I will file a user story. Thinking out loud for x86: If I understand correctly, push/pop operations work on whatever memory segment is i

How do you propose to implement returning an error code to the user? This isn't the heap... Andrew Sent: Sunday, September 25, 2016 3:32 AM To: Boie, Andrew P <andrew.p.boie(a)intel.com> Cc: devel(a)l

How would you propose to implement such a border protection? Andrew

I agree with Andy for reasons above, plus if you *did* move it, it would be subject to our deprecation policy (maintain both APIs for two releases with the old one marked __deprecated). Andrew

I contend this doesn't belong in the base ring buffer implementation either. I feel you are assuming that this policy of waiting is appropriate for all situations and I disagree. Ring buffers aren't j

Just to qualify this -- if you wanted to create a general purpose kernel object type that builds on what is in ring_buffer.h, I would not be opposed. But I want the existing definition left as-is as i

NACK, for reasons below. The header is currently in misc/ring_buffer.h. This is available to applications, why do you want to move it? Why do you think the names need to be changed? No, don't bake thi

+1 on deprecation! Andrew

Originally Vinayak sent a patch to change ARM's irq_enable() not to unpend any pending interrupts when enabling the channel. It was -1 as we didn't want to change the semantics of the kernel API to pr

relevant guest exception handling, but that apparently not happen. I'm not sure how we could get QEMU's stubs in Zephyr's IDT to be honest. It may be the case that we could do some work on the Zephyr

Historical note: originally, any given arch had just one interrupt controller implementation written (APIC for x86, NVIC for ARM, etc) so it was not separated out and was tightly coupled with the arch

Should be the end of November. We are on a 3 month release cycle. Work is done out in the open, just clone the 'master' branch of the Zephyr git tree if you want to see the latest and greatest. Andrew

Fine w/this. OK with this, what's the use-case though? NACK. This isn't easily portable to other arches. You brought this up as a candidate to replace irq_offload(), but irq_offload() only exists as a

If you rebase to 1.5.0 we changed ARM to use the GCC compiler builtins for atomic operations. There's also a C implementation, look for atomic_c.c Andrew

? Any idea why the checking doesn't "catch" the "problem"? Because it's perfectly valid C code. Doxygen's C parser is suboptimal and freaks out if you try to do function annotations. Which is how addi

Edit doc/doxygen.config, look for PREDEFINED, add "__deprecated=" to the list. This causes Doxygen to treat __deprecated as a predefined macro which expands to nothing. Andrew