Kernel Configuration Options¶
Kconfig files describe build-time configuration options (called symbols
in Kconfig-speak), how they’re grouped into menus and sub-menus, and
dependencies between them that determine what configurations are valid.
Kconfig files appear throughout the directory tree. For example,
subsys/power/Kconfig defines power-related options.
This documentation is generated automatically from the Kconfig files by
the gen_kconfig_rest.py script. Click on symbols for more
information.
Configuration Options¶
Symbol name |
Help/prompt |
|---|---|
This priority level is for end-user drivers such as sensors and display which have no inward dependencies. |
|
It’s possible that an architecture port cannot or does not want to use the provided k_busy_wait(), but instead must do something custom. It must enable this option in that case. |
|
It’s possible that an architecture port cannot use _Swap() to swap to the _main() thread, but instead must do something custom. It must enable this option in that case. |
|
This hidden option is selected by the target architecture if architecture-specific data is needed on a per memory domain basis. If so, the architecture defines a ‘struct arch_mem_domain’ which is embedded within every struct k_mem_domain. The architecture must also define the arch_mem_domain_init() function to set this up when a memory domain is created. Typical uses might be a set of page tables for that memory domain. |
|
This hidden option is selected by the target architecture if modifying a memory domain’s partitions at runtime, or changing a memory domain’s thread membership requires synchronous calls into the architecture layer. If enabled, the architecture layer must implement the following APIs: arch_mem_domain_thread_add arch_mem_domain_thread_remove arch_mem_domain_partition_remove arch_mem_domain_partition_add arch_mem_domain_destroy It’s important to note that although supervisor threads can be members of memory domains, they have no implications on supervisor thread access to memory. Memory domain APIs may only be invoked from supervisor mode. For these reasons, on uniprocessor systems unless memory access policy is managed in separate software constructions like page tables, these APIs don’t need to be implemented as the underlying memory management hardware will be reprogrammed on context switch anyway. |
|
Use the compiler builtin functions for atomic operations. This is the preferred method. However, support for all arches in GCC is incomplete. |
|
Use atomic operations routines that are implemented entirely in C by locking interrupts. Selected by architectures which either do not have support for atomic operations in their instruction set, or haven’t been implemented yet during bring-up, and also the compiler does not have support for the atomic __sync_* builtins. |
|
Use when there isn’t support for compiler built-ins, but you have written optimized assembly code under arch/ which implements these. |
|
This option outputs a banner to the console device during boot up. |
|
This option delays bootup for the specified amount of milliseconds. This is used to allow serial ports to get ready before starting to print information on them during boot, as some systems might boot to fast for a receiving endpoint to detect the new USB serial bus, enumerate it and get ready to receive before it actually gets data. A similar effect can be achieved by waiting for DCD on the serial port–however, not all serial ports have DCD. |
|
Untrusted parameters from user mode may be used in system calls to index arrays during speculative execution, also known as the Spectre V1 vulnerability. When enabled, various macros defined in misc/speculation.h will insert fence instructions or other appropriate mitigations after bounds checking any array index parameters passed in from untrusted sources (user mode threads). When disabled, these macros do nothing. |
|
Enable per-thread errno in the kernel. Application and library code must include errno.h provided by the C library (libc) to use the errno symbol. The C library must access the per-thread errno via the z_errno() symbol. |
|
Use thread local storage to store errno instead of storing it in the kernel thread struct. This avoids a syscall if userspace is enabled. |
|
When enabled, will enforce that a writable page isn’t executable and vice versa. This might not be acceptable in all scenarios, so this option is given for those unafraid of shooting themselves in the foot. If unsure, say Y. |
|
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. A size of zero means that no heap memory pool is defined. |
|
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. |
|
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. |
|
This option specifies the size of the stack used by interrupt service routines (ISRs), and during kernel initialization. |
|
When available and selected, the kernel will build in a mode where all shared data is placed in multiprocessor-coherent (generally “uncached”) memory. Thread stacks will remain cached, as will application memory declared with __incoherent. This is intended for Zephyr SMP kernels running on cache-incoherent architectures only. Note that when this is selected, there is an implicit API change that assumes cache coherence to any memory passed to the kernel. Code that creates kernel data structures in uncached regions may fail strangely. Some assertions exist to catch these mistakes, but not all circumstances can be tested. |
|
Default minimal init priority for each init level. |
|
Device driver, that depends on common components, such as interrupt controller, but does not depend on other devices, uses this init priority. |
|
Kernel objects use this priority for initialization. This priority needs to be higher than minimal default initialization priority. |
|
Enable the use of kernel memory pool. Say y if unsure. |
|
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(). |
|
Priority at which the initialization thread runs, including the start of the main() function. main() can then change its priority if desired. |
|
Configure the maximum number of partitions per memory domain. |
|
This adds variable to the k_mem_slab structure to hold maximum utilization of the slab. |
|
Number of multiprocessing-capable cores available to the multicpu API and SMP features. |
|
Disabling this option is DEPRECATED. 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. |
|
Number of cooperative priorities configured in the system. Gives access to priorities:
or seen another way, priorities:
This can be set to zero to disable cooperative scheduling. Cooperative threads always preempt preemptible threads. Each priority requires an extra 8 bytes of RAM. Each set of 32 extra total priorities require an extra 4 bytes and add one possible iteration to loops that search for the next thread to run. The total number of priorities is
The extra one is for the idle thread, which must run at the lowest priority, and be the only thread at that priority. |
|
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. |
|
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. |
|
This option specifies the total number of asynchronous pipe messages that can exist simultaneously, across all pipes in the system. Setting this option to 0 disables support for asynchronous pipe messages. |
|
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. Each priority requires an extra 8 bytes of RAM. Each set of 32 extra total priorities require an extra 4 bytes and add one possible iteration to loops that search for the next thread to run. The total number of priorities is
The extra one is for the idle thread, which must run at the lowest priority, and be the only thread at that priority. |
|
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). |
|
Priority inheritance ceiling |
|
When true, the application will have access to the k_thread_cpu_mask_*() APIs which control per-CPU affinity masks in SMP mode, allowing applications to pin threads to specific CPUs or disallow threads from running on given CPUs. Note that as currently implemented, this involves an inherent O(N) scaling in the number of idle-but-runnable threads, and thus works only with the DUMB scheduler (as SCALABLE and MULTIQ would see no benefit). Note that this setting does not technically depend on SMP and is implemented without it for testing purposes, but for obvious reasons makes sense as an application API only where there is more than one CPU. With one CPU, it’s just a higher overhead version of k_thread_start/stop(). |
|
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. |
|
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. |
|
True if the architecture supports a call to arch_sched_ipi() to broadcast an interrupt that will call z_sched_ipi() on other CPUs in the system. Required for k_thread_abort() to operate with reasonable latency (otherwise we might have to wait for the other thread to take an interrupt, which can be arbitrarily far in the future). |
|
When selected, the scheduler ready queue will be implemented as the classic/textbook array of lists, one per priority (max 32 priorities). This corresponds to the scheduler algorithm used in Zephyr versions prior to 1.12. It incurs only a tiny code size overhead vs. the “dumb” 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, and SMP affinity which need to traverse the list of threads. Typical applications with small numbers of runnable threads probably want the DUMB scheduler. |
|
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. |
|
When true, kernel will be built with SMP support, allowing more than one CPU to schedule Zephyr tasks at a time. |
|
This option enables compiler stack canaries. 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 can result in a significant increase in footprint and an associated decrease in performance. If stack canaries are not supported by the compiler an error will occur at build time. |
|
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. |
|
On some architectures, the _Swap() primitive cannot be made atomic with respect to the irq_lock being released. That is, interrupts may be received between the entry to _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. |
|
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. |
|
System workqueue stack size |
|
This option specifies that the kernel lacks timer support. Some device configurations can eliminate significant code if this is disabled. Obviously timeout-related APIs will not work. |
|
This option specifies hardware clock. |
|
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 bookeeping. 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. |
|
This option allows each thread to store 32 bits of custom data, which can be accessed using the k_thread_custom_data_xxx() APIs. |
|
This option enables thread local storage (TLS) support in kernel. |
|
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. |
|
This option instructs the kernel to maintain a list of all threads (excluding those that have not yet started or have already terminated). |
|
This option allows to set a name for a thread. |
|
Gather thread runtime statistics.
|
|
Use timing functions to gather thread runtime statistics. Note that timing functions may use a different timer than the default timer for OS timekeeping. |
|
This option allows each thread to store the thread stack info into the k_thread data structure. |
|
This option suppresses periodic system clock interrupts whenever the kernel becomes idle. This permits the system to remain in a power saving state for extended periods without having to wake up to service each tick as it occurs. |
|
This option enables clock interrupt suppression when the kernel idles for only a short period of time. It specifies the minimum number of ticks that must occur before the next kernel timer expires in order for suppression to happen. |
|
This option enables a fully event driven kernel. Periodic system clock interrupt generation would be stopped at all times. |
|
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). |
|
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. |
|
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). |
|
This option enables time slicing between preemptible threads of equal priority. |
|
Hidden option to signal that toolchain supports generating code with thread local storage. |
|
When true, it will add a hook into z_sched_ipi(), in order to check if schedule IPI has called or not, for testing purpose. |
|
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. |
|
Indicates whether _arch_switch() API is supported by the currently enabled platform. This option should be selected by platforms that implement it. |
|
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. |
|
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_DUMB (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). |
|
This option allows the kernel to operate with its text and read-only sections residing in ROM (or similar read-only memory). Not all boards support this option so it must be used with care; you must also supply a linker command file when building your image. Enabling this option increases both the code and data footprint of the image. |