# Kernel configuration options # Copyright (c) 2014-2015 Wind River Systems, Inc. # SPDX-License-Identifier: Apache-2.0 menu "General Kernel Options" module = KERNEL module-str = kernel source "subsys/logging/Kconfig.template.log_config" config MULTITHREADING bool "Multi-threading" if ARCH_HAS_SINGLE_THREAD_SUPPORT default y select RING_BUFFER help If disabled, only the main thread is available, so a main() function must be provided. Interrupts are available. Kernel objects will most probably not behave as expected, especially with regards to pending, since the main thread cannot pend, it being the only thread in the system. Many drivers and subsystems will not work with this option set to 'n'; disable only when you REALLY know what you are doing. config NUM_COOP_PRIORITIES int "Number of coop priorities" if MULTITHREADING default 1 if !MULTITHREADING default 16 range 0 128 help Number of cooperative priorities configured in the system. Gives access to priorities: K_PRIO_COOP(0) to K_PRIO_COOP(CONFIG_NUM_COOP_PRIORITIES - 1) or seen another way, priorities: -CONFIG_NUM_COOP_PRIORITIES to -1 This can be set to zero to disable cooperative scheduling. Cooperative threads always preempt preemptible threads. The total number of priorities is NUM_COOP_PRIORITIES + NUM_PREEMPT_PRIORITIES + 1 The extra one is for the idle thread, which must run at the lowest priority, and be the only thread at that priority. config NUM_PREEMPT_PRIORITIES int "Number of preemptible priorities" if MULTITHREADING default 0 if !MULTITHREADING default 15 range 0 127 help Number of preemptible priorities available in the system. Gives access to priorities 0 to CONFIG_NUM_PREEMPT_PRIORITIES - 1. This can be set to 0 to disable preemptible scheduling. The total number of priorities is NUM_COOP_PRIORITIES + NUM_PREEMPT_PRIORITIES + 1 The extra one is for the idle thread, which must run at the lowest priority, and be the only thread at that priority. config MAIN_THREAD_PRIORITY int "Priority of initialization/main thread" default -2 if !PREEMPT_ENABLED default 0 help Priority at which the initialization thread runs, including the start of the main() function. main() can then change its priority if desired. config COOP_ENABLED def_bool (NUM_COOP_PRIORITIES != 0) config PREEMPT_ENABLED def_bool (NUM_PREEMPT_PRIORITIES != 0) config MUTEX_DEADLOCK_DETECT bool "Mutex deadlock detection" depends on ASSERT default y help Detect mutex deadlock cycles at lock time for K_FOREVER waits. When a K_FOREVER lock attempt would form a cycle in the ownership chain and every cycle member also waits forever, an assertion is triggered. Cycles where any member has a finite timeout are not flagged since they recover naturally via -EAGAIN. This detection is part of the priority inheritance chain-walk and has no effect if CONFIG_PRIORITY_CEILING is set at or below the idle thread's priority, which disables priority inheritance (and this detection along with it). config PRIORITY_CEILING int "Priority inheritance ceiling" default -128 range -128 127 help This defines the minimum priority value (i.e. the logically highest priority) that a thread will acquire as part of the k_mutex priority inheritance. Setting this to a priority level at or lower than the the idle thread's priority level disables the k_mutex priority inheritance algorithm. config NUM_METAIRQ_PRIORITIES int "Number of very-high priority 'preemptor' threads" default 0 help This defines a set of priorities at the (numerically) lowest end of the range which have "meta-irq" behavior. Runnable threads at these priorities will always be scheduled before threads at lower priorities, EVEN IF those threads are otherwise cooperative and/or have taken a scheduler lock. Making such a thread runnable in any way thus has the effect of "interrupting" the current task and running the meta-irq thread synchronously, like an exception or system call. The intent is to use these priorities to implement "interrupt bottom half" or "tasklet" behavior, allowing driver subsystems to return from interrupt context but be guaranteed that user code will not be executed (on the current CPU) until the remaining work is finished. As this breaks the "promise" of non-preemptibility granted by the current API for cooperative threads, this tool probably shouldn't be used from application code. config SCHED_DEADLINE bool "Earliest-deadline-first scheduling" help This enables a simple "earliest deadline first" scheduling mode where threads can set "deadline" deltas measured in k_cycle_get_32() units. Priority decisions within (!!) a single priority will choose the next expiring deadline and not simply the least recently added thread. config MAIN_STACK_SIZE int "Size of stack for initialization and main thread" default 2048 if COVERAGE_GCOV default 512 if ZTEST && !(RISCV || X86 || ARM || ARC || OPENRISC) default 1024 help When the initialization is complete, the thread executing it then executes the main() routine, so as to reuse the stack used by the initialization, which would be wasted RAM otherwise. After initialization is complete, the thread runs main(). config IDLE_STACK_SIZE int "Size of stack for idle thread" default 2048 if COVERAGE_GCOV default 1024 if XTENSA default 512 if RISCV default 384 if DYNAMIC_OBJECTS default 320 if ARC || (ARM && CPU_HAS_FPU) || (X86 && MMU) default 256 help Depending on the work that the idle task must do, most likely due to power management but possibly to other features like system event logging (e.g. logging when the system goes to sleep), the idle thread may need more stack space than the default value. config ISR_STACK_SIZE int "ISR and initialization stack size (in bytes)" default 2048 help This option specifies the size of the stack used by interrupt service routines (ISRs), and during kernel initialization. config THREAD_STACK_INFO bool "Thread stack info" help This option allows each thread to store the thread stack info into the k_thread data structure. config THREAD_STACK_MEM_MAPPED bool "Stack to be memory mapped at runtime" depends on MMU && ARCH_SUPPORTS_MEM_MAPPED_STACKS select THREAD_STACK_INFO select THREAD_ABORT_NEED_CLEANUP help This option changes behavior where the thread stack is memory mapped with guard pages on both ends to catch undesired accesses. config THREAD_ABORT_HOOK bool help Used by portability layers to modify locally managed status mask. config THREAD_ABORT_NEED_CLEANUP bool help This option enables the bits to clean up the current thread if k_thread_abort(_current) is called, as the cleanup cannot be running in the current thread stack. config THREAD_CUSTOM_DATA bool "Thread custom data" help This option allows each thread to store 32 bits of custom data, which can be accessed using the k_thread_custom_data_xxx() APIs. config DYNAMIC_THREAD bool "Support for dynamic threads [EXPERIMENTAL]" select EXPERIMENTAL depends on THREAD_STACK_INFO select DYNAMIC_OBJECTS if USERSPACE select THREAD_MONITOR help Enable support for dynamic threads and stacks. if DYNAMIC_THREAD config DYNAMIC_THREAD_STACK_SIZE int "Size of each pre-allocated thread stack" default 4096 if X86 || COVERAGE_GCOV default 1024 if !X86 && !64BIT default 2048 if !X86 && 64BIT help Default stack size (in bytes) for dynamic threads. config DYNAMIC_THREAD_ALLOC bool "Support heap-allocated thread objects and stacks" help Select this option to enable allocating thread object and thread stacks from the system heap. Only use this type of allocation in situations where malloc is permitted. config DYNAMIC_THREAD_POOL_SIZE int "Number of statically pre-allocated threads" default 0 range 0 8192 help Pre-allocate a fixed number of thread objects and stacks at build time. This type of "dynamic" stack is usually suitable in situations where malloc is not permitted. choice DYNAMIC_THREAD_PREFER prompt "Preferred dynamic thread allocator" default DYNAMIC_THREAD_PREFER_POOL help If both CONFIG_DYNAMIC_THREAD_ALLOC=y and CONFIG_DYNAMIC_THREAD_POOL_SIZE > 0, then the user may specify the order in which allocation is attempted. config DYNAMIC_THREAD_PREFER_ALLOC bool "Prefer heap-based allocation" depends on DYNAMIC_THREAD_ALLOC help Select this option to attempt a heap-based allocation prior to any pool-based allocation. config DYNAMIC_THREAD_PREFER_POOL bool "Prefer pool-based allocation" help Select this option to attempt a pool-based allocation prior to any heap-based allocation. endchoice # DYNAMIC_THREAD_PREFER endif # DYNAMIC_THREADS choice SCHED_ALGORITHM prompt "Scheduler priority queue algorithm" default SCHED_SIMPLE help The kernel can be built with several choices for the ready queue implementation, offering different choices between code size, constant factor runtime overhead and performance scaling when many threads are added. config SCHED_SIMPLE bool "Simple linked-list ready queue" help When selected, the scheduler ready queue will be implemented as a simple unordered list, with very fast constant time performance for single threads and very low code size. Choose this on systems with constrained code size that will never see more than a small number (3, maybe) of runnable threads in the queue at any given time. On most platforms (that are not otherwise using the red/black tree) this results in a savings of ~2k of code size. config SCHED_SCALABLE bool "Red/black tree ready queue" help When selected, the scheduler ready queue will be implemented as a red/black tree. This has rather slower constant-time insertion and removal overhead, and on most platforms (that are not otherwise using the rbtree somewhere) requires an extra ~2kb of code. But the resulting behavior will scale cleanly and quickly into the many thousands of threads. Use this on platforms where you may have many threads (very roughly: more than 20 or so) marked as runnable at a given time. Most applications don't want this. config SCHED_MULTIQ bool "Traditional multi-queue ready queue" depends on !SCHED_DEADLINE help When selected, the scheduler ready queue will be implemented as the classic/textbook array of lists, one per priority. This corresponds to the scheduler algorithm used in Zephyr versions prior to 1.12. It incurs only a tiny code size overhead vs. the "simple" scheduler and runs in O(1) time in almost all circumstances with very low constant factor. But it requires a fairly large RAM budget to store those list heads, and the limited features make it incompatible with features like deadline scheduling that need to sort threads more finely. Typical applications with small numbers of runnable threads probably want the simple scheduler. endchoice # SCHED_ALGORITHM choice WAITQ_ALGORITHM prompt "Wait queue priority algorithm" default WAITQ_SIMPLE help The wait_q abstraction used in IPC primitives to pend threads for later wakeup shares the same backend data structure choices as the scheduler, and can use the same options. config WAITQ_SCALABLE bool "Use scalable wait_q implementation" help When selected, the wait_q will be implemented with a balanced tree. Choose this if you expect to have many threads waiting on individual primitives. There is a ~2kb code size increase over WAITQ_SIMPLE (which may be shared with SCHED_SCALABLE) if the rbtree is not used elsewhere in the application, and pend/unpend operations on "small" queues will be somewhat slower (though this is not generally a performance path). config WAITQ_SIMPLE bool "Simple linked-list wait_q" help When selected, the wait_q will be implemented with a doubly-linked list. Choose this if you expect to have only a few threads blocked on any single IPC primitive. endchoice # WAITQ_ALGORITHM config SEM_LOCK_STRIPES int "Number of semaphore spinlock stripes" if SMP default 1 range 1 256 help Number of spinlocks used to synchronize semaphore operations. This value must be a power of two. The default is one system-wide lock, which preserves the existing semaphore behavior and memory footprint. Non-SMP systems always use one lock. Additional stripes reduce serialization and hash collisions on SMP systems at the cost of additional static memory. Stripes are not individually cache-line aligned. With 4-byte spinlocks and a 64-byte cache line, 16 stripes fit within a single cache line. Increasing the count beyond 16 can also reduce cache-line contention. menu "Misc Kernel related options" config CURRENT_THREAD_USE_NO_TLS bool help Hidden symbol to not use thread local storage to store current thread. config CURRENT_THREAD_USE_TLS bool "Store current thread in thread local storage (TLS)" depends on THREAD_LOCAL_STORAGE && !CURRENT_THREAD_USE_NO_TLS default y help Use thread local storage to store the current thread. This avoids a syscall if userspace is enabled. config NONZERO_SPINLOCK_SIZE bool "Force spinlock to have non-zero size" help This option indicates that the spinlock structure must have a non-zero size (such as if used in an array). It is automatically selected when using C++. endmenu menu "Kernel Debugging and Metrics" config INIT_STACKS bool "Initialize stack areas" help This option instructs the kernel to initialize stack areas with a known value (0xaa) before they are first used, so that the high water mark can be easily determined. This applies to the stack areas for threads, as well as to the interrupt stack. config SKIP_BSS_CLEAR bool help This option disables software .bss section zeroing during Zephyr initialization. Such boot-time optimization could be used for platforms where .bss section is zeroed-out externally. Please pay attention that when this option is enabled the responsibility for .bss zeroing in all possible scenarios (mind e.g. SW reset) is delegated to the external SW or HW. config THREAD_MONITOR bool "Thread monitoring" help This option instructs the kernel to maintain a list of all threads (excluding those that have not yet started or have already terminated). config THREAD_NAME bool "Thread name" help This option allows to set a name for a thread. config THREAD_MAX_NAME_LEN int "Max length of a thread name" default 32 default 64 if ZTEST range 8 128 depends on THREAD_NAME help Thread names get stored in the k_thread struct. Indicate the max name length, including the terminating NULL byte. Reduce this value to conserve memory. config INSTRUMENT_THREAD_SWITCHING bool menuconfig THREAD_RUNTIME_STATS bool "Thread runtime statistics" help Gather thread runtime statistics. For example: - Thread total execution cycles - System total execution cycles if THREAD_RUNTIME_STATS config THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS bool "Use timing functions to gather statistics" select TIMING_FUNCTIONS_NEED_AT_BOOT help Use timing functions to gather thread runtime statistics. Note that timing functions may use a different timer than the default timer for OS timekeeping. config SCHED_THREAD_USAGE bool "Collect thread runtime usage" default y select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH help Collect thread runtime info at context switch time config SCHED_THREAD_USAGE_ANALYSIS bool "Analyze the collected thread runtime usage statistics" default n depends on SCHED_THREAD_USAGE select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH help Collect additional timing information related to thread scheduling for analysis purposes. This includes the total time that a thread has been scheduled, the longest time for which it was scheduled and others. config SCHED_THREAD_USAGE_ALL bool "Collect total system runtime usage" default y if SCHED_THREAD_USAGE depends on SCHED_THREAD_USAGE help Maintain a sum of all non-idle thread cycle usage. config SCHED_THREAD_USAGE_AUTO_ENABLE bool "Automatically enable runtime usage statistics" default y depends on SCHED_THREAD_USAGE help When set, this option automatically enables the gathering of both the thread and CPU usage statistics. endif # THREAD_RUNTIME_STATS menuconfig THREAD_RUNTIME_STACK_SAFETY bool "Thread runtime stack safety support" default n help This option enables support for the thread runtime stack safety check routines. These routines are used to detect a thread's unused stack space and invoke a user-defined handler if it was found to have dropped below a configured threshold. if THREAD_RUNTIME_STACK_SAFETY config THREAD_RUNTIME_STACK_SAFETY_DEFAULT_UNUSED_THRESHOLD_PCT int "Runtime Stack Safety unused stack usage percentage threshold" default 0 range 0 99 help This option specifies a thread's default runtime stack safety threshold as a percentage of the stack size. When the runtime stack safety routines detect that a thread's unused stack percentage has fallen _below_ this threshold, a user-defined handler is invoked. Setting this to 0 disables the check by default for all threads. endif endmenu rsource "Kconfig.obj_core" config WORKQUEUE_WORK_TIMEOUT bool "Support workqueue work timeout monitoring" help If enabled, the workqueue will monitor the duration of each work item. If the work item handler takes longer than the specified time to execute, the work queue thread will be aborted, and an error will be logged. menu "System Work Queue Options" config SYSTEM_WORKQUEUE_STACK_SIZE int "System workqueue stack size" default 4096 if COVERAGE_GCOV || WIFI_NRF70 default 2560 if WIFI_NM_WPA_SUPPLICANT default 1024 config SYSTEM_WORKQUEUE_PRIORITY int "System workqueue priority" default -2 if COOP_ENABLED && !PREEMPT_ENABLED default 0 if !COOP_ENABLED default -1 help By default, system work queue priority is the lowest cooperative priority. This means that any work handler, once started, won't be preempted by any other thread until finished. config SYSTEM_WORKQUEUE_NO_YIELD bool "Select whether system work queue yields" help By default, the system work queue yields between each work item, to prevent other threads from being starved. Selecting this removes this yield, which may be useful if the work queue thread is cooperative and a sequence of work items is expected to complete without yielding. config SYSTEM_WORKQUEUE_WORK_TIMEOUT_MS int "Select system work queue work timeout in milliseconds" default 5000 if ASSERT default 0 help Set to 0 to disable work timeout for system workqueue. Option has no effect if WORKQUEUE_WORK_TIMEOUT is not enabled. endmenu menu "Barrier Operations" config BARRIER_OPERATIONS_BUILTIN bool help Use the compiler builtin functions for barrier operations. This is the preferred method. However, support for all arches in GCC is incomplete. config BARRIER_OPERATIONS_ARCH bool help Use when there isn't support for compiler built-ins, but you have written optimized assembly code under arch/ which implements these. endmenu menu "Timer API Options" config TIMESLICING bool "Thread time slicing" default y depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0) help This option enables time slicing between preemptible threads of equal priority. config TIMESLICE_SIZE int "Time slice size (in ms)" default 20 range 0 $(INT32_MAX) depends on TIMESLICING help This option specifies the maximum amount of time a thread can execute before other threads of equal priority are given an opportunity to run. A time slice size of zero means "no limit" (i.e. an infinitely large time slice). config TIMESLICE_PRIORITY int "Time slicing thread priority ceiling" default 0 range 0 NUM_PREEMPT_PRIORITIES depends on TIMESLICING help This option specifies the thread priority level at which time slicing takes effect; threads having a higher priority than this ceiling are not subject to time slicing. config TIMESLICE_PER_THREAD bool "Support per-thread timeslice values" depends on TIMESLICING help When set, this enables an API for setting timeslice values on a per-thread basis, with an application callback invoked when a thread reaches the end of its timeslice. config TIMER_OBSERVER bool "Support extension points for k_timer lifecycle" help Adds iterable‑section support for observing k_timer events. Supports extending timer behavior without kernel changes. endmenu menu "Other Kernel Object Options" config POLL bool "Async I/O Framework" help Asynchronous notification framework. Enable the k_poll() and k_poll_signal_raise() APIs. The former can wait on multiple events concurrently, which can be either directly triggered or triggered by the availability of some kernel objects (semaphores and FIFOs). config MEM_SLAB_POINTER_VALIDATE bool "Validate the memory slab pointer when allocating or freeing" default ASSERT help This enables additional runtime checks to validate the memory slab pointer during when allocating or freeing a memory slab. config MEM_SLAB_TRACE_MAX_UTILIZATION bool "Getting maximum slab utilization" help This adds variable to the k_mem_slab structure to hold maximum utilization of the slab. config NUM_MBOX_ASYNC_MSGS int "Maximum number of in-flight asynchronous mailbox messages" default 10 help This option specifies the total number of asynchronous mailbox messages that can exist simultaneously, across all mailboxes in the system. Setting this option to 0 disables support for asynchronous mailbox messages. config EVENTS bool "Event objects" depends on MULTITHREADING help This option enables event objects. Threads may wait on event objects for specific events, but both threads and ISRs may deliver events to event objects. Note that setting this option slightly increases the size of the thread structure. config KERNEL_MEM_POOL bool "Use Kernel Memory Pool" default y help Enable the use of kernel memory pool. Say y if unsure. if KERNEL_MEM_POOL config HEAP_MEM_POOL_SIZE int "Heap memory pool size (in bytes)" default 0 help This option specifies the size of the heap memory pool used when dynamically allocating memory using k_malloc(). The maximum size of the memory pool is only limited to available memory. If subsystems specify HEAP_MEM_POOL_ADD_SIZE_* options, these will be added together and the sum will be compared to the HEAP_MEM_POOL_SIZE value. If the sum is greater than the HEAP_MEM_POOL_SIZE option (even if this has the default 0 value), then the actual heap size will be rounded up to the sum of the individual requirements (unless the HEAP_MEM_POOL_IGNORE_MIN option is enabled). If the final value, after considering both this option as well as sum of the custom requirements, ends up being zero, then no system heap will be available. config HEAP_MEM_POOL_IGNORE_MIN bool "Ignore the minimum heap memory pool requirement" help This option can be set to force setting a smaller heap memory pool size than what's specified by enabled subsystems. This can be useful when optimizing memory usage and a more precise minimum heap size is known for a given application. endif # KERNEL_MEM_POOL endmenu config SWAP_NONATOMIC bool help On some architectures, the z_swap() primitive cannot be made atomic with respect to the irq_lock being released. That is, interrupts may be received between the entry to z_swap and the completion of the context switch. There are a handful of workaround cases in the kernel that need to be enabled when this is true. Currently, this only happens on ARM when the PendSV exception priority sits below that of Zephyr-handled interrupts. config ARCH_HAS_THREAD_NAME_HOOK bool help The architecture provides a hook to handle thread name changes beyond just storing it in the kernel structure. config SYS_CLOCK_TICKS_PER_SEC int "System tick frequency (in ticks/second)" default 100 if QEMU_TARGET || SOC_POSIX default 10000 if TICKLESS_KERNEL default 100 help This option specifies the nominal frequency of the system clock in Hz. For asynchronous timekeeping, the kernel defines a "ticks" concept. A "tick" is the internal count in which the kernel does all its internal uptime and timeout bookkeeping. Interrupts are expected to be delivered on tick boundaries to the extent practical, and no fractional ticks are tracked. The choice of tick rate is configurable by this option. Also the number of cycles per tick should be chosen so that 1 millisecond is exactly represented by an integral number of ticks. Defaults on most hardware platforms (ones that support setting arbitrary interrupt timeouts) are expected to be in the range of 10 kHz, with software emulation platforms and legacy drivers using a more traditional 100 Hz value. Note that when available and enabled, in "tickless" mode this config variable specifies the minimum available timing granularity, not necessarily the number or frequency of interrupts delivered to the kernel. A value of 0 completely disables timer support in the kernel. config SYS_CLOCK_HW_CYCLES_PER_SEC int "System clock's h/w timer frequency" default 0 if TIMER_READS_ITS_FREQUENCY_AT_RUNTIME depends on SYS_CLOCK_EXISTS help This option specifies the frequency of the hardware timer used for the system clock (in Hz). This option is set by the SOC's or board's Kconfig file and the user should generally avoid modifying it via the menu configuration. config SYS_CLOCK_EXISTS bool "System clock exists and is enabled" default y help This option specifies that the kernel has timer support. Some device configurations can eliminate significant code if this is disabled. Obviously timeout-related APIs will not work when disabled. config TIMEOUT_64BIT bool "Store kernel timeouts in 64 bit precision" default y help When this option is true, the k_ticks_t values passed to kernel APIs will be a 64 bit quantity, allowing the use of larger values (and higher precision tick rates) without fear of overflowing the 32 bit word. This feature also gates the availability of absolute timeout values (which require the extra precision). choice TIMEOUT_BACKEND prompt "Timeout queue backend" default TIMEOUT_BACKEND_DLIST depends on SYS_CLOCK_EXISTS help Selects the data structure used by the kernel timeout subsystem to track pending timeouts. All backends share the same front-end (kernel/timeout.c); they differ only in the queue representation and its performance trade-offs. config TIMEOUT_BACKEND_DLIST bool "Sorted delta list" help The original Zephyr backend: a doubly linked list sorted by expiry, each node storing a delta to its predecessor. Insertion is O(n), head removal O(1). No capacity limit and no extra static RAM. The right default for most systems. config TIMEOUT_BACKEND_MINHEAP bool "Binary min-heap [EXPERIMENTAL]" depends on TIMEOUT_64BIT select EXPERIMENTAL help A binary min-heap keyed on absolute expiry tick. Insertion and arbitrary removal are O(log n). Requires 64-bit timeouts and a fixed-capacity heap (CONFIG_TIMEOUT_HEAP_MAX_ENTRIES); overflow is a fatal error. Consider this when many timeouts are pending and insertion cost on the delta list dominates. config TIMEOUT_BACKEND_WHEEL bool "Hierarchical timer wheel [EXPERIMENTAL]" select EXPERIMENTAL help A hierarchical timer wheel: O(1) insertion and removal for timeouts expiring within the next ~1024 ticks, with a sorted overflow list for anything beyond. Sift work is amortised at 32-tick boundaries. Best when many short-lived timeouts are pending. Costs ~1 KB of static state, so it is a poor fit for very small-RAM targets, and it does not guarantee same-tick firing order. config TIMEOUT_BACKEND_BUCKET bool "Single-level bucketed delta list [EXPERIMENTAL]" depends on TIMEOUT_64BIT select EXPERIMENTAL help A simpler relative of the timer wheel: one per-tick bucket list for the next CONFIG_TIMEOUT_BUCKET_LISTS ticks (O(1) insert/remove) plus a sorted overflow list for anything beyond (O(n) insert). Migration is on demand against the actual next event, so it imposes no tickless-idle floor. Requires 64-bit timeouts. config TIMEOUT_BACKEND_SKIPLIST bool "Skip list [EXPERIMENTAL]" depends on TIMEOUT_64BIT select EXPERIMENTAL help A Pugh skip list keyed on absolute expiry tick. Expected insertion and arbitrary removal are O(log n), the earliest timeout is O(1), and there is no capacity limit. Same-tick firing order is FIFO. Each pending timeout carries CONFIG_TIMEOUT_SKIPLIST_MAX_LEVEL forward pointers, sized for the worst case although the expected height is 2. At the default 8 levels struct _timeout is 88 bytes on a 64-bit target, against 32 for the delta list and 24 for the min-heap, and every k_thread, k_timer and delayable work item pays it. Requires 64-bit timeouts. Consider this when many timeouts are pending and a bounded heap is undesirable. endchoice # TIMEOUT_BACKEND config TIMEOUT_BUCKET_LISTS int "Number of per-tick buckets for the bucketed backend" depends on TIMEOUT_BACKEND_BUCKET default 32 range 8 64 help Number of single-tick bucket lists (must be a power of two between 8 and 64). Timeouts expiring within this many ticks get O(1) insertion; longer ones land in the sorted overflow list. Larger values widen the O(1) window at the cost of more static RAM (one list head each). Below 8 the plain delta-list backend is likely the better choice. The occupancy bitmap is a uint32_t for up to 32 buckets, a uint64_t beyond. config TIMEOUT_SKIPLIST_MAX_LEVEL int "Maximum skip-list height" depends on TIMEOUT_BACKEND_SKIPLIST default 8 range 4 16 help Maximum number of forward-pointer levels in each timeout node. Height is drawn from a geometric(1/2) distribution, so expected search cost is O(log n) as long as this is at least log2 of the peak number of pending timeouts. Each extra level adds one pointer to every struct _timeout (k_timer, k_thread, delayable work, ...). 8 levels cover a few hundred concurrent timeouts comfortably. config TIMEOUT_HEAP_MAX_ENTRIES int "Maximum simultaneous pending timeouts in the heap" depends on TIMEOUT_BACKEND_MINHEAP default 128 help Static capacity of the timeout min-heap array. Set this to the peak number of simultaneously pending timeouts your application requires. As a starting point, count: - Active threads (each may have one pending timeout) - Active k_timer instances - Delayable work items - Network / socket timeouts Overflow causes k_panic() at runtime. If you see unexpected panics, increase this value and rebuild. config SYS_CLOCK_MAX_TIMEOUT_DAYS int "Max timeout (in days) used in conversions" default 365 help Value is used in the time conversion static inline function to determine at compile time which algorithm to use. One algorithm is faster, takes less code but may overflow if multiplication of source and target frequency exceeds 64 bits. Second algorithm prevents that. Faster algorithm is selected for conversion if maximum timeout represented in source frequency domain multiplied by target frequency fits in 64 bits. config BUSYWAIT_CPU_LOOPS_PER_USEC int "Number of CPU loops per microsecond for crude busy looping" depends on !SYS_CLOCK_EXISTS && !ARCH_HAS_CUSTOM_BUSY_WAIT default 500 help Calibration for crude CPU based busy loop duration. The default is assuming 1 GHz CPU and 2 cycles per loop. Reality is certainly much worse but all we want here is a ball-park figure that ought to be good enough for the purpose of being able to configure out system timer support. If accuracy is very important then implementing arch_busy_wait() should be considered. menu "Security Options" config REQUIRES_STACK_CANARIES bool help Hidden option to signal that software stack protection is required. choice prompt "Stack canaries protection options" optional help If stack canaries are supported by the compiler, it will emit extra code that inserts a canary value into the stack frame when a function is entered and validates this value upon exit. Stack corruption (such as that caused by buffer overflow) results in a fatal error condition for the running entity. Enabling this option, depending on the level chosen, can result in a significant increase in footprint and a corresponding decrease in performance. If stack canaries are not supported by the compiler an error will occur at build time. config STACK_CANARIES bool "Default protection" depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS select REQUIRES_STACK_CANARIES help This option enables compiler stack canaries in functions that have vulnerable objects. Generally this means function that call alloca or have buffers larger than 8 bytes. config STACK_CANARIES_STRONG bool "Strong protection" depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS select REQUIRES_STACK_CANARIES help This option enables compiler stack canaries in functions that call alloca, functions that have local array definition or have references to local frame addresses. config STACK_CANARIES_ALL bool "Maximum protection available" depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS select REQUIRES_STACK_CANARIES help This option enables compiler stack canaries for all functions. config STACK_CANARIES_EXPLICIT bool "Explicit protection" depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR depends on "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS select REQUIRES_STACK_CANARIES help This option enables compiler stack canaries only in functions which have the stack_protect attribute. endchoice if REQUIRES_STACK_CANARIES config STACK_CANARIES_TLS bool "Stack canaries using thread local storage" depends on THREAD_LOCAL_STORAGE depends on ARCH_HAS_STACK_CANARIES_TLS # Clang's RISC-V backend rejects the -mstack-protector-guard=tls family of # flags, so the canary cannot be anchored to the TLS base register. Without # them Clang emits an absolute reference to the thread-local __stack_chk_guard # symbol (which resolves to address 0), producing an image that faults in the # prologue of the first canary-instrumented function. Disallow the # combination so it cannot be selected into a silently broken build. depends on !(RISCV && "$(TOOLCHAIN_VARIANT_COMPILER)" = "llvm") help This option enables compiler stack canaries on TLS. Stack canaries will leave in the thread local storage and each thread will have its own canary. This makes harder to predict the canary location and value. When enabled this causes an additional performance penalty during thread creations because it needs a new random value per thread. endif config STACK_POINTER_RANDOM int "Initial stack pointer randomization bounds" depends on !STACK_GROWS_UP depends on MULTITHREADING depends on TEST_RANDOM_GENERATOR || ENTROPY_HAS_DRIVER default 0 help This option performs a limited form of Address Space Layout Randomization by offsetting some random value to a thread's initial stack pointer upon creation. This hinders some types of security attacks by making the location of any given stack frame non-deterministic. This feature can waste up to the specified size in bytes the stack region, which is carved out of the total size of the stack region. A reasonable minimum value would be around 100 bytes if this can be spared. This is currently only implemented for systems whose stack pointers grow towards lower memory addresses. config HW_SHADOW_STACK bool "Use hardware shadow stack mechanism to provide stack protection [EXPERIMENTAL]" depends on ARCH_HAS_HW_SHADOW_STACK select EXPERIMENTAL help This option enables the use of hardware shadow stack to provide stack protection. When enabled, threads that provide a shadow stack will use the hardware shadow stack to store the return address of function calls. This will help to protect against return-oriented programming (ROP) attacks. Currently, not all threads created by the kernel will have a shadow stack. Indeed, threads need to manually attach a shadow stack to use this feature. See the documentation for more information. config HW_SHADOW_STACK_PERCENTAGE_SIZE int "Percentage of the stack size used to define shadow stack size" depends on HW_SHADOW_STACK default 30 range 0 100 help This option specifies the percentage of the stack to be used for shadow stack. The value is a percentage of the total stack size. The default value is 30%, which means that the shadow stack size will be 30% of the stack size, in *addition* to the stack size. used for shadow stack. Note that this size is constrained by the HW_SHADOW_STACK_MIN_SIZE config option. config HW_SHADOW_STACK_MIN_SIZE int "Minimum size of the hardware shadow stack" depends on HW_SHADOW_STACK default 256 help This option specifies the minimum size of the hardware shadow stack, in bytes, so that threads that use minimal stack size can still have a sensible shadow stack size. The default value is 256 bytes, which means that the shadow stack size will be at least 256 bytes, even if the percentage defined via HW_SHADOW_STACK_PERCENTAGE_SIZE would define a smaller size. config HW_SHADOW_STACK_ALLOW_REUSE bool "Allow reuse of the shadow stack" depends on HW_SHADOW_STACK default y if ZTEST help This option allows the reuse of the shadow stack. This is meant to accommodate thread reuse, when the same thread is created again, such as done by the test suite. It is not meant to be used to share the shadow stack between threads. endmenu rsource "userspace/Kconfig" config USE_SWITCH bool "Use new-style _arch_switch instead of arch_swap" depends on USE_SWITCH_SUPPORTED help The _arch_switch() API is a lower level context switching primitive than the original arch_swap mechanism. It is required for an SMP-aware scheduler, or if the architecture does not provide arch_swap. In uniprocess situations where the architecture provides both, _arch_switch incurs more somewhat overhead and may be slower. config USE_SWITCH_SUPPORTED bool help Indicates whether _arch_switch() API is supported by the currently enabled platform. This option should be selected by platforms that implement it. rsource "smp/Kconfig" config TICKLESS_KERNEL bool "Tickless kernel" default y if TICKLESS_CAPABLE depends on TICKLESS_CAPABLE help This option enables a fully event driven kernel. Periodic system clock interrupt generation would be stopped at all times. config TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE bool default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" || "$(ZEPHYR_TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE)" = "y" help Hidden option to signal that toolchain supports generating code with thread local storage. config THREAD_LOCAL_STORAGE bool "Thread Local Storage (TLS)" depends on ARCH_HAS_THREAD_LOCAL_STORAGE && TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE select NEED_LIBC_MEM_PARTITION if (CPU_CORTEX_M && USERSPACE) help This option enables thread local storage (TLS) support in kernel. config KERNEL_WHOLE_ARCHIVE bool help This option forces every object file in the libkernel.a archive to be included, rather than searching the archive for required object files. config TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU # As of today, we don't know of any toolchains that don't create # either .ctors or .init_array sections containing initializer # addresses in a fashion compatible with how Zephyr uses them. def_bool y config STATIC_INIT_GNU bool "Support GNU-compatible initializers and constructors" default y if CPP || NATIVE_LIBRARY || COVERAGE depends on TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU depends on !CMAKE_LINKER_GENERATOR help GNU-compatible initialization of static objects. This is required for C++ constructor support as well as for initializer functions as defined by GNU-compatible toolchains. This increases the size of Zephyr binaries by around 24 bytes. If you know your application doesn't need any initializers, you can disable this option. The linker will emit an error if constructors are needed and this option has been disabled. config DEVICE_API_ASSERT bool "Assert on DEVICE_API_GET" default y depends on ASSERT help Enable asserts on DEVICE_API_GET checking for NULL pointers and device API type, disable to save some flash space. endmenu config KERNEL_NO_LTO bool depends on LTO depends on XIP help Some SoCs require kernel code to be placed in RAM, which makes link-time optimization (LTO) unsuitable for these files (-fno-lto). Disabling LTO allows the affected code to be linked as separate objects and placed in specific memory regions. Running kernel code from RAM can improve execution performance, especially for timing-critical routines or context switch paths. rsource "Kconfig.device" rsource "Kconfig.vm" rsource "Kconfig.init"