If you disable CONFIG_MULTITHREADING, the scheduler goes away. The kernel operates in coop-mode only with a single thread, which is basically "never preempt me, except by interrupts and when that happ

Yeah, but that is not backwards-compatible with the API. And that only works for timers, not the other APIs that take timeouts. Although, that might be irrelevant. Interesting idea. That could be a ne

ns or us, you still needed 64-bit timeouts for either, which ended up being the major concern. 64-bit math can be costly: we've seen stack usage increase of 80 bytes on some architectures. Also, I don

Hi Mike, When prototyping the new API, I started with timeouts as an int64_t in nanoseconds, to allow the same precision as struct timespec, but without the akwardness of having to create an instance

Yet another example that shows the importance of laying out early what the different MPU regions will be used for, as stated in the top comment in my original reply to the RFC.

Agreed, but I think this can be made optional if the application is trusted and user-space is used more as a debugging aid. Although, that's Yet Another Kconfig configuration to verify.

Hi Jun, <duration> is the time before the first timer expiry, and <period> is the period at which it will expiry subsenquently. If you specify a <period> of 0, the timer only fire once. e.g. If the cu

Some random thoughts on this, do with them as you wish. :) To get more detailed feedback, I think you need to document how exactly you intend on using the MPU. Like: - region 0 to protect the kernel t

Sorry, I did not have much time to look at this. But yes, this looks indeed like a problem even in the pre-unified kernel (per-1.6).

The GDB server was used in WR Rocket, a product based on an early zephyr codebase. It was used for both loading images and debugging when a hardware solution was not available, such as on the Intel Ga

Hi Michael, This does not really solve your problem, but Zephyr 1.6 contains a legacy layer that provides all the APIs of the old kernels on top of the new kernel. It's not a NOP to move to 1.6, since

Hi, Should be supported on architectures where the hardware has support for it. It is a feature of the kernel. ARM, ARC, x86 do support it. Not entirely sure about Nios2 and RiscV. Regards, Ben

Hi, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm not sure what this means... This code is valid. The scheduler lock is per-thread. If the thread goes to sleep, it relinquishes the CPU, but when it co

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In the latest code base, that's not a valid state: only bits 0-5 are used, giving a max value of 0x3f. ./kernel/include/kernel_structs.h:#define _THREAD_DUMMY (1 << 0

OK, so it seems that, since you can disable the CONFIG_SEMAPHORE_GROUPS feature, you are _not_ using said feature. In theory, this if statement should always be hit in handle_sem_group(): if (!(thread

Sure, a panic() API is a good thing to have as well. Like you said, this is for a completely different use-case then the current __ASSERT() we have.

Agreed, and that is why the kernel takes the approach below: __ASSERT()s are use to catch user errors early during development, and are meant to be turned off before deployment.

Hi Marcus, The approache taken by the core kernel is pretty simple: - if an error happens because it's the user's fault, __ASSERT(): the kernel doesn't care, you did something stupid :) - if the error

[..snip..] [..snip..] Well, that was an in-depth explanation of what is happening internally, but I focused too much on what your code was doing that I kinda overlooked a better way of doing what you

That's basically it. IMHO, I think that this reasoning was bogus anyway, and only meant we had (probably worse) re-implementation of some libc routines, with different names, or not. :-/ +1.