I really think that officially supporting both printk() and printf() in the kernel is a bad idea. Having Zephyr depend on libc APIs really isn't the way to go. Zephyr should not care whether printf()

Why do you need this for the LOAPIC/IOAPIC? All its functions are private to the kernel and do not require a device pointer. Please provide a specific example on where you would need to run device_get

The best thing to do if you find code defects is one of two things: 1. Send a patch to Gerrit that fixes it for review. 2. File a bug in JIRA https://jira.zephyrproject.org/ so that the issue is track

Of course, but I don't know if at the time we were thinking about supporting a bunch of variants of a particular microcontroller that are almost the same. I think this is an opportunity for iterative

Do we need another layer of abstraction in the build for SoC variants? I share Dan's concerns, I think it may be better to have st_stm32/ SoC and then subdirectories with variants thereof, with common

+1 from me

Sure, let me know. If it ends up you need a dynamic handler for one specific exception on x86 we could treat it as a special case. irq_offload() is like this. Andrew

Problem statement: We currently have two separate implementations on how to connect interrupts on all arches: static IRQs and dynamic IRQs. On x86 only we also have static and dynamic APIs for connect

With all due respect what are you talking about? Tickless idle and PM are orthogonal! Tickless idle means we don't come out of idle to just serve periodic timer interrupts, we come out of idle for the