1# Kernel configuration options
2
3# Copyright (c) 2014-2015 Wind River Systems, Inc.
4# SPDX-License-Identifier: Apache-2.0
5
6menu "General Kernel Options"
7
8module = KERNEL
9module-str = kernel
10source "subsys/logging/Kconfig.template.log_config"
11
12config MULTITHREADING
13	bool "Multi-threading" if ARCH_HAS_SINGLE_THREAD_SUPPORT
14	default y
15	select RING_BUFFER
16	help
17	  If disabled, only the main thread is available, so a main() function
18	  must be provided. Interrupts are available. Kernel objects will most
19	  probably not behave as expected, especially with regards to pending,
20	  since the main thread cannot pend, it being the only thread in the
21	  system.
22
23	  Many drivers and subsystems will not work with this option
24	  set to 'n'; disable only when you REALLY know what you are
25	  doing.
26
27config NUM_COOP_PRIORITIES
28	int "Number of coop priorities" if MULTITHREADING
29	default 1 if !MULTITHREADING
30	default 16
31	range 0 128
32	help
33	  Number of cooperative priorities configured in the system. Gives access
34	  to priorities:
35
36		K_PRIO_COOP(0) to K_PRIO_COOP(CONFIG_NUM_COOP_PRIORITIES - 1)
37
38	  or seen another way, priorities:
39
40		-CONFIG_NUM_COOP_PRIORITIES to -1
41
42	  This can be set to zero to disable cooperative scheduling. Cooperative
43	  threads always preempt preemptible threads.
44
45	  The total number of priorities is
46
47	   NUM_COOP_PRIORITIES + NUM_PREEMPT_PRIORITIES + 1
48
49	  The extra one is for the idle thread, which must run at the lowest
50	  priority, and be the only thread at that priority.
51
52config NUM_PREEMPT_PRIORITIES
53	int "Number of preemptible priorities" if MULTITHREADING
54	default 0 if !MULTITHREADING
55	default 15
56	range 0 127
57	help
58	  Number of preemptible priorities available in the system. Gives access
59	  to priorities 0 to CONFIG_NUM_PREEMPT_PRIORITIES - 1.
60
61	  This can be set to 0 to disable preemptible scheduling.
62
63	  The total number of priorities is
64
65	   NUM_COOP_PRIORITIES + NUM_PREEMPT_PRIORITIES + 1
66
67	  The extra one is for the idle thread, which must run at the lowest
68	  priority, and be the only thread at that priority.
69
70config MAIN_THREAD_PRIORITY
71	int "Priority of initialization/main thread"
72	default -2 if !PREEMPT_ENABLED
73	default 0
74	help
75	  Priority at which the initialization thread runs, including the start
76	  of the main() function. main() can then change its priority if desired.
77
78config COOP_ENABLED
79	def_bool (NUM_COOP_PRIORITIES != 0)
80
81config PREEMPT_ENABLED
82	def_bool (NUM_PREEMPT_PRIORITIES != 0)
83
84config PRIORITY_CEILING
85	int "Priority inheritance ceiling"
86	default -127
87	help
88	  This defines the minimum priority value (i.e. the logically
89	  highest priority) that a thread will acquire as part of
90	  k_mutex priority inheritance.
91
92config NUM_METAIRQ_PRIORITIES
93	int "Number of very-high priority 'preemptor' threads"
94	default 0
95	help
96	  This defines a set of priorities at the (numerically) lowest
97	  end of the range which have "meta-irq" behavior.  Runnable
98	  threads at these priorities will always be scheduled before
99	  threads at lower priorities, EVEN IF those threads are
100	  otherwise cooperative and/or have taken a scheduler lock.
101	  Making such a thread runnable in any way thus has the effect
102	  of "interrupting" the current task and running the meta-irq
103	  thread synchronously, like an exception or system call.  The
104	  intent is to use these priorities to implement "interrupt
105	  bottom half" or "tasklet" behavior, allowing driver
106	  subsystems to return from interrupt context but be guaranteed
107	  that user code will not be executed (on the current CPU)
108	  until the remaining work is finished.  As this breaks the
109	  "promise" of non-preemptibility granted by the current API
110	  for cooperative threads, this tool probably shouldn't be used
111	  from application code.
112
113config SCHED_DEADLINE
114	bool "Earliest-deadline-first scheduling"
115	help
116	  This enables a simple "earliest deadline first" scheduling
117	  mode where threads can set "deadline" deltas measured in
118	  k_cycle_get_32() units.  Priority decisions within (!!) a
119	  single priority will choose the next expiring deadline and
120	  not simply the least recently added thread.
121
122config SCHED_CPU_MASK
123	bool "CPU mask affinity/pinning API"
124	depends on SCHED_SIMPLE
125	help
126	  When true, the application will have access to the
127	  k_thread_cpu_mask_*() APIs which control per-CPU affinity masks in
128	  SMP mode, allowing applications to pin threads to specific CPUs or
129	  disallow threads from running on given CPUs.  Note that as currently
130	  implemented, this involves an inherent O(N) scaling in the number of
131	  idle-but-runnable threads, and thus works only with the simple
132	  scheduler (as SCALABLE and MULTIQ would see no benefit).
133
134	  Note that this setting does not technically depend on SMP and is
135	  implemented without it for testing purposes, but for obvious reasons
136	  makes sense as an application API only where there is more than one
137	  CPU.  With one CPU, it's just a higher overhead version of
138	  k_thread_start/stop().
139
140config SCHED_CPU_MASK_PIN_ONLY
141	bool "CPU mask variant with single-CPU pinning only"
142	depends on SMP && SCHED_CPU_MASK
143	help
144	  When true, enables a variant of SCHED_CPU_MASK where only
145	  one CPU may be specified for every thread.  Effectively, all
146	  threads have a single "assigned" CPU and they will never be
147	  scheduled symmetrically.  In general this is not helpful,
148	  but some applications have a carefully designed threading
149	  architecture and want to make their own decisions about how
150	  to assign work to CPUs.  In that circumstance, some moderate
151	  optimizations can be made (e.g. having a separate run queue
152	  per CPU, keeping the list length shorter). When selected,
153	  the CPU mask becomes an immutable thread attribute. It can
154	  only be modified before a thread is started.  Most
155	  applications don't want this.
156
157config MAIN_STACK_SIZE
158	int "Size of stack for initialization and main thread"
159	default 2048 if COVERAGE_GCOV
160	default 512 if ZTEST && !(RISCV || X86 || ARM || ARC)
161	default 1024
162	help
163	  When the initialization is complete, the thread executing it then
164	  executes the main() routine, so as to reuse the stack used by the
165	  initialization, which would be wasted RAM otherwise.
166
167	  After initialization is complete, the thread runs main().
168
169config IDLE_STACK_SIZE
170	int "Size of stack for idle thread"
171	default 2048 if COVERAGE_GCOV
172	default 1024 if XTENSA
173	default 512 if RISCV
174	default 384 if DYNAMIC_OBJECTS
175	default 320 if ARC || (ARM && CPU_HAS_FPU) || (X86 && MMU)
176	default 256
177	help
178	  Depending on the work that the idle task must do, most likely due to
179	  power management but possibly to other features like system event
180	  logging (e.g. logging when the system goes to sleep), the idle thread
181	  may need more stack space than the default value.
182
183config ISR_STACK_SIZE
184	int "ISR and initialization stack size (in bytes)"
185	default 2048
186	help
187	  This option specifies the size of the stack used by interrupt
188	  service routines (ISRs), and during kernel initialization.
189
190config THREAD_STACK_INFO
191	bool "Thread stack info"
192	help
193	  This option allows each thread to store the thread stack info into
194	  the k_thread data structure.
195
196config THREAD_STACK_MEM_MAPPED
197	bool "Stack to be memory mapped at runtime"
198	depends on MMU && ARCH_SUPPORTS_MEM_MAPPED_STACKS
199	select THREAD_STACK_INFO
200	select THREAD_ABORT_NEED_CLEANUP
201	help
202	  This option changes behavior where the thread stack is memory
203	  mapped with guard pages on both ends to catch undesired
204	  accesses.
205
206config THREAD_ABORT_HOOK
207	bool
208	help
209	  Used by portability layers to modify locally managed status mask.
210
211config THREAD_ABORT_NEED_CLEANUP
212	bool
213	help
214	  This option enables the bits to clean up the current thread if
215	  k_thread_abort(_current) is called, as the cleanup cannot be
216	  running in the current thread stack.
217
218config THREAD_CUSTOM_DATA
219	bool "Thread custom data"
220	help
221	  This option allows each thread to store 32 bits of custom data,
222	  which can be accessed using the k_thread_custom_data_xxx() APIs.
223
224config THREAD_USERSPACE_LOCAL_DATA
225	bool
226	depends on USERSPACE
227	default y if ERRNO && !ERRNO_IN_TLS && !LIBC_ERRNO
228
229config USERSPACE_THREAD_MAY_RAISE_PRIORITY
230	bool "Thread can raise own priority"
231	depends on USERSPACE
232	depends on TEST # This should only be enabled by tests.
233	help
234	  Thread can raise its own priority in userspace mode.
235
236config DYNAMIC_THREAD
237	bool "Support for dynamic threads [EXPERIMENTAL]"
238	select EXPERIMENTAL
239	depends on THREAD_STACK_INFO
240	select DYNAMIC_OBJECTS if USERSPACE
241	select THREAD_MONITOR
242	help
243	  Enable support for dynamic threads and stacks.
244
245if DYNAMIC_THREAD
246
247config DYNAMIC_THREAD_STACK_SIZE
248	int "Size of each pre-allocated thread stack"
249	default 4096 if X86 || COVERAGE_GCOV
250	default 1024 if !X86 && !64BIT
251	default 2048 if !X86 && 64BIT
252	help
253	  Default stack size (in bytes) for dynamic threads.
254
255config DYNAMIC_THREAD_ALLOC
256	bool "Support heap-allocated thread objects and stacks"
257	help
258	  Select this option to enable allocating thread object and
259	  thread stacks from the system heap.
260
261	  Only use this type of allocation in situations
262	  where malloc is permitted.
263
264config DYNAMIC_THREAD_POOL_SIZE
265	int "Number of statically pre-allocated threads"
266	default 0
267	range 0 8192
268	help
269	  Pre-allocate a fixed number of thread objects and
270	  stacks at build time.
271
272	  This type of "dynamic" stack is usually suitable in
273	  situations where malloc is not permitted.
274
275choice DYNAMIC_THREAD_PREFER
276	prompt "Preferred dynamic thread allocator"
277	default DYNAMIC_THREAD_PREFER_POOL
278	help
279	  If both CONFIG_DYNAMIC_THREAD_ALLOC=y and
280	  CONFIG_DYNAMIC_THREAD_POOL_SIZE > 0, then the user may
281	  specify the order in which allocation is attempted.
282
283config DYNAMIC_THREAD_PREFER_ALLOC
284	bool "Prefer heap-based allocation"
285	depends on DYNAMIC_THREAD_ALLOC
286	help
287	  Select this option to attempt a heap-based allocation
288	  prior to any pool-based allocation.
289
290config DYNAMIC_THREAD_PREFER_POOL
291	bool "Prefer pool-based allocation"
292	help
293	  Select this option to attempt a pool-based allocation
294	  prior to any heap-based allocation.
295
296endchoice # DYNAMIC_THREAD_PREFER
297
298endif # DYNAMIC_THREADS
299
300config SCHED_DUMB
301	bool "Simple linked-list ready queue"
302	select DEPRECATED
303	help
304	  Deprecated in favour of SCHED_SIMPLE.
305
306choice SCHED_ALGORITHM
307	prompt "Scheduler priority queue algorithm"
308	default SCHED_SIMPLE if SCHED_DUMB
309	default SCHED_SIMPLE
310	help
311	  The kernel can be built with several choices for the
312	  ready queue implementation, offering different choices between
313	  code size, constant factor runtime overhead and performance
314	  scaling when many threads are added.
315
316config SCHED_SIMPLE
317	bool "Simple linked-list ready queue"
318	help
319	  When selected, the scheduler ready queue will be implemented
320	  as a simple unordered list, with very fast constant time
321	  performance for single threads and very low code size.
322	  Choose this on systems with constrained code size that will
323	  never see more than a small number (3, maybe) of runnable
324	  threads in the queue at any given time.  On most platforms
325	  (that are not otherwise using the red/black tree) this
326	  results in a savings of ~2k of code size.
327
328config SCHED_SCALABLE
329	bool "Red/black tree ready queue"
330	help
331	  When selected, the scheduler ready queue will be implemented
332	  as a red/black tree.  This has rather slower constant-time
333	  insertion and removal overhead, and on most platforms (that
334	  are not otherwise using the rbtree somewhere) requires an
335	  extra ~2kb of code.  But the resulting behavior will scale
336	  cleanly and quickly into the many thousands of threads.  Use
337	  this on platforms where you may have many threads (very
338	  roughly: more than 20 or so) marked as runnable at a given
339	  time.  Most applications don't want this.
340
341config SCHED_MULTIQ
342	bool "Traditional multi-queue ready queue"
343	depends on !SCHED_DEADLINE
344	help
345	  When selected, the scheduler ready queue will be implemented
346	  as the classic/textbook array of lists, one per priority.
347	  This corresponds to the scheduler algorithm used in Zephyr
348	  versions prior to 1.12.  It incurs only a tiny code size
349	  overhead vs. the "simple" scheduler and runs in O(1) time
350	  in almost all circumstances with very low constant factor.
351	  But it requires a fairly large RAM budget to store those list
352	  heads, and the limited features make it incompatible with
353	  features like deadline scheduling that need to sort threads
354	  more finely, and SMP affinity which need to traverse the list
355	  of threads.  Typical applications with small numbers of runnable
356	  threads probably want the simple scheduler.
357
358endchoice # SCHED_ALGORITHM
359
360config WAITQ_DUMB
361	bool "Simple linked-list wait_q"
362	select DEPRECATED
363	help
364	  Deprecated in favour of WAITQ_SIMPLE.
365
366choice WAITQ_ALGORITHM
367	prompt "Wait queue priority algorithm"
368	default WAITQ_SIMPLE if WAITQ_DUMB
369	default WAITQ_SIMPLE
370	help
371	  The wait_q abstraction used in IPC primitives to pend
372	  threads for later wakeup shares the same backend data
373	  structure choices as the scheduler, and can use the same
374	  options.
375
376config WAITQ_SCALABLE
377	bool "Use scalable wait_q implementation"
378	help
379	  When selected, the wait_q will be implemented with a
380	  balanced tree.  Choose this if you expect to have many
381	  threads waiting on individual primitives.  There is a ~2kb
382	  code size increase over WAITQ_SIMPLE (which may be shared with
383	  SCHED_SCALABLE) if the rbtree is not used elsewhere in the
384	  application, and pend/unpend operations on "small" queues
385	  will be somewhat slower (though this is not generally a
386	  performance path).
387
388config WAITQ_SIMPLE
389	bool "Simple linked-list wait_q"
390	help
391	  When selected, the wait_q will be implemented with a
392	  doubly-linked list.  Choose this if you expect to have only
393	  a few threads blocked on any single IPC primitive.
394
395endchoice # WAITQ_ALGORITHM
396
397menu "Misc Kernel related options"
398config LIBC_ERRNO
399	bool
400	help
401	  Use external libc errno, not the internal one. This eliminates any
402	  locally allocated errno storage and usage.
403
404config ERRNO
405	bool "Errno support"
406	default y
407	help
408	  Enable per-thread errno in the kernel. Application and library code must
409	  include errno.h provided by the C library (libc) to use the errno
410	  symbol. The C library must access the per-thread errno via the
411	  z_errno() symbol.
412
413config ERRNO_IN_TLS
414	bool "Store errno in thread local storage (TLS)"
415	depends on ERRNO && THREAD_LOCAL_STORAGE && !LIBC_ERRNO
416	default y
417	help
418	  Use thread local storage to store errno instead of storing it in
419	  the kernel thread struct. This avoids a syscall if userspace is enabled.
420
421config CURRENT_THREAD_USE_NO_TLS
422	bool
423	help
424	  Hidden symbol to not use thread local storage to store current
425	  thread.
426
427config CURRENT_THREAD_USE_TLS
428	bool "Store current thread in thread local storage (TLS)"
429	depends on THREAD_LOCAL_STORAGE && !CURRENT_THREAD_USE_NO_TLS
430	default y
431	help
432	  Use thread local storage to store the current thread. This avoids a
433	  syscall if userspace is enabled.
434
435endmenu
436
437menu "Kernel Debugging and Metrics"
438
439config INIT_STACKS
440	bool "Initialize stack areas"
441	help
442	  This option instructs the kernel to initialize stack areas with a
443	  known value (0xaa) before they are first used, so that the high
444	  water mark can be easily determined. This applies to the stack areas
445	  for threads, as well as to the interrupt stack.
446
447config SKIP_BSS_CLEAR
448	bool
449	help
450	  This option disables software .bss section zeroing during Zephyr
451	  initialization. Such boot-time optimization could be used for
452	  platforms where .bss section is zeroed-out externally.
453	  Please pay attention that when this option is enabled
454	  the responsibility for .bss zeroing in all possible scenarios
455	  (mind e.g. SW reset) is delegated to the external SW or HW.
456
457config BOOT_BANNER
458	bool "Boot banner"
459	default y
460	select PRINTK
461	select EARLY_CONSOLE
462	help
463	  This option outputs a banner to the console device during boot up.
464
465config BOOT_BANNER_STRING
466	string "Boot banner string"
467	depends on BOOT_BANNER
468	default "Booting Zephyr OS build"
469	help
470	  Use this option to set the boot banner.
471
472config BOOT_DELAY
473	int "Boot delay in milliseconds"
474	depends on MULTITHREADING
475	default 0
476	help
477	  This option delays bootup for the specified amount of
478	  milliseconds. This is used to allow serial ports to get ready
479	  before starting to print information on them during boot, as
480	  some systems might boot to fast for a receiving endpoint to
481	  detect the new USB serial bus, enumerate it and get ready to
482	  receive before it actually gets data. A similar effect can be
483	  achieved by waiting for DCD on the serial port--however, not
484	  all serial ports have DCD.
485
486config BOOT_CLEAR_SCREEN
487	bool "Clear screen"
488	help
489	  Use this option to clear the screen before printing anything else.
490	  Using a VT100 enabled terminal on the client side is required for this to work.
491
492config THREAD_MONITOR
493	bool "Thread monitoring"
494	help
495	  This option instructs the kernel to maintain a list of all threads
496	  (excluding those that have not yet started or have already
497	  terminated).
498
499config THREAD_NAME
500	bool "Thread name"
501	help
502	  This option allows to set a name for a thread.
503
504config THREAD_MAX_NAME_LEN
505	int "Max length of a thread name"
506	default 32
507	default 64 if ZTEST
508	range 8 128
509	depends on THREAD_NAME
510	help
511	  Thread names get stored in the k_thread struct. Indicate the max
512	  name length, including the terminating NULL byte. Reduce this value
513	  to conserve memory.
514
515config INSTRUMENT_THREAD_SWITCHING
516	bool
517
518menuconfig THREAD_RUNTIME_STATS
519	bool "Thread runtime statistics"
520	help
521	  Gather thread runtime statistics.
522
523	  For example:
524	    - Thread total execution cycles
525	    - System total execution cycles
526
527if THREAD_RUNTIME_STATS
528
529config THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS
530	bool "Use timing functions to gather statistics"
531	select TIMING_FUNCTIONS_NEED_AT_BOOT
532	help
533	  Use timing functions to gather thread runtime statistics.
534
535	  Note that timing functions may use a different timer than
536	  the default timer for OS timekeeping.
537
538config SCHED_THREAD_USAGE
539	bool "Collect thread runtime usage"
540	default y
541	select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH
542	help
543	  Collect thread runtime info at context switch time
544
545config SCHED_THREAD_USAGE_ANALYSIS
546	bool "Analyze the collected thread runtime usage statistics"
547	default n
548	depends on SCHED_THREAD_USAGE
549	select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH
550	help
551	  Collect additional timing information related to thread scheduling
552	  for analysis purposes. This includes the total time that a thread
553	  has been scheduled, the longest time for which it was scheduled and
554	  others.
555
556config SCHED_THREAD_USAGE_ALL
557	bool "Collect total system runtime usage"
558	default y if SCHED_THREAD_USAGE
559	depends on SCHED_THREAD_USAGE
560	help
561	  Maintain a sum of all non-idle thread cycle usage.
562
563config SCHED_THREAD_USAGE_AUTO_ENABLE
564	bool "Automatically enable runtime usage statistics"
565	default y
566	depends on SCHED_THREAD_USAGE
567	help
568	  When set, this option automatically enables the gathering of both
569	  the thread and CPU usage statistics.
570
571endif # THREAD_RUNTIME_STATS
572
573menuconfig THREAD_RUNTIME_STACK_SAFETY
574	bool "Thread runtime stack safety support"
575	default n
576	help
577	  This option enables support for the thread runtime stack safety check routines.
578	  These routines are used to  detect a thread's unused stack space and invoke a
579	  user-defined handler if it was found to have dropped below a configured threshold.
580
581if THREAD_RUNTIME_STACK_SAFETY
582config THREAD_RUNTIME_STACK_SAFETY_DEFAULT_UNUSED_THRESHOLD_PCT
583	int "Runtime Stack Safety unused stack usage percentage threshold"
584	default 0
585	range 0 99
586	help
587	  This option specifies a thread's default runtime stack safety
588	  threshold as a percentage of the stack size. When the runtime stack
589	  safety routines detect that a thread's unused stack percentage has fallen
590	  _below_ this threshold, a user-defined handler is invoked.
591	  Setting this to 0 disables the check by default for all threads.
592endif
593
594endmenu
595
596rsource "Kconfig.obj_core"
597
598config WORKQUEUE_WORK_TIMEOUT
599	bool "Support workqueue work timeout monitoring"
600	help
601	  If enabled, the workqueue will monitor the duration of each work item.
602	  If the work item handler takes longer than the specified time to
603	  execute, the work queue thread will be aborted, and an error will be
604	  logged.
605
606menu "System Work Queue Options"
607config SYSTEM_WORKQUEUE_STACK_SIZE
608	int "System workqueue stack size"
609	default 4096 if COVERAGE_GCOV || WIFI_NRF70
610	default 2560 if WIFI_NM_WPA_SUPPLICANT
611	default 1024
612
613config SYSTEM_WORKQUEUE_PRIORITY
614	int "System workqueue priority"
615	default -2 if COOP_ENABLED && !PREEMPT_ENABLED
616	default  0 if !COOP_ENABLED
617	default -1
618	help
619	  By default, system work queue priority is the lowest cooperative
620	  priority. This means that any work handler, once started, won't
621	  be preempted by any other thread until finished.
622
623config SYSTEM_WORKQUEUE_NO_YIELD
624	bool "Select whether system work queue yields"
625	help
626	  By default, the system work queue yields between each work item, to
627	  prevent other threads from being starved.  Selecting this removes
628	  this yield, which may be useful if the work queue thread is
629	  cooperative and a sequence of work items is expected to complete
630	  without yielding.
631
632config SYSTEM_WORKQUEUE_WORK_TIMEOUT_MS
633	int "Select system work queue work timeout in milliseconds"
634	default 5000 if ASSERT
635	default 0
636	help
637	  Set to 0 to disable work timeout for system workqueue. Option
638	  has no effect if WORKQUEUE_WORK_TIMEOUT is not enabled.
639
640endmenu
641
642menu "Barrier Operations"
643config BARRIER_OPERATIONS_BUILTIN
644	bool
645	help
646	  Use the compiler builtin functions for barrier operations. This is
647	  the preferred method. However, support for all arches in GCC is
648	  incomplete.
649
650config BARRIER_OPERATIONS_ARCH
651	bool
652	help
653	  Use when there isn't support for compiler built-ins, but you have
654	  written optimized assembly code under arch/ which implements these.
655endmenu
656
657menu "Atomic Operations"
658config ATOMIC_OPERATIONS_BUILTIN
659	bool
660	help
661	  Use the compiler builtin functions for atomic operations. This is
662	  the preferred method. However, support for all arches in GCC is
663	  incomplete.
664
665config ATOMIC_OPERATIONS_ARCH
666	bool
667	help
668	  Use when there isn't support for compiler built-ins, but you have
669	  written optimized assembly code under arch/ which implements these.
670
671config ATOMIC_OPERATIONS_C
672	bool
673	help
674	  Use atomic operations routines that are implemented entirely
675	  in C by locking interrupts. Selected by architectures which either
676	  do not have support for atomic operations in their instruction
677	  set, or haven't been implemented yet during bring-up, and also
678	  the compiler does not have support for the atomic __sync_* builtins.
679endmenu
680
681menu "Timer API Options"
682
683config TIMESLICING
684	bool "Thread time slicing"
685	default y
686	depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0)
687	help
688	  This option enables time slicing between preemptible threads of
689	  equal priority.
690
691config TIMESLICE_SIZE
692	int "Time slice size (in ms)"
693	default 20
694	range 0 $(INT32_MAX)
695	depends on TIMESLICING
696	help
697	  This option specifies the maximum amount of time a thread can execute
698	  before other threads of equal priority are given an opportunity to run.
699	  A time slice size of zero means "no limit" (i.e. an infinitely large
700	  time slice).
701
702config TIMESLICE_PRIORITY
703	int "Time slicing thread priority ceiling"
704	default 0
705	range 0 NUM_PREEMPT_PRIORITIES
706	depends on TIMESLICING
707	help
708	  This option specifies the thread priority level at which time slicing
709	  takes effect; threads having a higher priority than this ceiling are
710	  not subject to time slicing.
711
712config TIMESLICE_PER_THREAD
713	bool "Support per-thread timeslice values"
714	depends on TIMESLICING
715	help
716	  When set, this enables an API for setting timeslice values on
717	  a per-thread basis, with an application callback invoked when
718	  a thread reaches the end of its timeslice.
719
720endmenu
721
722menu "Other Kernel Object Options"
723
724config POLL
725	bool "Async I/O Framework"
726	help
727	  Asynchronous notification framework. Enable the k_poll() and
728	  k_poll_signal_raise() APIs.  The former can wait on multiple events
729	  concurrently, which can be either directly triggered or triggered by
730	  the availability of some kernel objects (semaphores and FIFOs).
731
732config MEM_SLAB_POINTER_VALIDATE
733	bool "Validate the memory slab pointer when allocating or freeing"
734	default ASSERT
735	help
736	  This enables additional runtime checks to validate the memory slab
737	  pointer during when allocating or freeing a memory slab.
738
739config MEM_SLAB_TRACE_MAX_UTILIZATION
740	bool "Getting maximum slab utilization"
741	help
742	  This adds variable to the k_mem_slab structure to hold
743	  maximum utilization of the slab.
744
745config NUM_MBOX_ASYNC_MSGS
746	int "Maximum number of in-flight asynchronous mailbox messages"
747	default 10
748	help
749	  This option specifies the total number of asynchronous mailbox
750	  messages that can exist simultaneously, across all mailboxes
751	  in the system.
752
753	  Setting this option to 0 disables support for asynchronous
754	  mailbox messages.
755
756config EVENTS
757	bool "Event objects"
758	depends on MULTITHREADING
759	help
760	  This option enables event objects. Threads may wait on event
761	  objects for specific events, but both threads and ISRs may deliver
762	  events to event objects.
763
764	  Note that setting this option slightly increases the size of the
765	  thread structure.
766
767config KERNEL_MEM_POOL
768	bool "Use Kernel Memory Pool"
769	default y
770	help
771	  Enable the use of kernel memory pool.
772
773	  Say y if unsure.
774
775if KERNEL_MEM_POOL
776
777config HEAP_MEM_POOL_SIZE
778	int "Heap memory pool size (in bytes)"
779	default 0
780	help
781	  This option specifies the size of the heap memory pool used when
782	  dynamically allocating memory using k_malloc(). The maximum size of
783	  the memory pool is only limited to available memory. If subsystems
784	  specify HEAP_MEM_POOL_ADD_SIZE_* options, these will be added together
785	  and the sum will be compared to the HEAP_MEM_POOL_SIZE value.
786	  If the sum is greater than the HEAP_MEM_POOL_SIZE option (even if this
787	  has the default 0 value), then the actual heap size will be rounded up
788	  to the sum of the individual requirements (unless the
789	  HEAP_MEM_POOL_IGNORE_MIN option is enabled). If the final value, after
790	  considering both this option as well as sum of the custom
791	  requirements, ends up being zero, then no system heap will be
792	  available.
793
794config HEAP_MEM_POOL_IGNORE_MIN
795	bool "Ignore the minimum heap memory pool requirement"
796	help
797	  This option can be set to force setting a smaller heap memory pool
798	  size than what's specified by enabled subsystems. This can be useful
799	  when optimizing memory usage and a more precise minimum heap size
800	  is known for a given application.
801
802endif # KERNEL_MEM_POOL
803
804endmenu
805
806config SWAP_NONATOMIC
807	bool
808	help
809	  On some architectures, the z_swap() primitive cannot be made
810	  atomic with respect to the irq_lock being released.  That
811	  is, interrupts may be received between the entry to z_swap
812	  and the completion of the context switch.  There are a
813	  handful of workaround cases in the kernel that need to be
814	  enabled when this is true.  Currently, this only happens on
815	  ARM when the PendSV exception priority sits below that of
816	  Zephyr-handled interrupts.
817
818config ARCH_HAS_THREAD_NAME_HOOK
819	bool
820	help
821	  The architecture provides a hook to handle thread name changes beyond
822	  just storing it in the kernel structure.
823
824config SYS_CLOCK_TICKS_PER_SEC
825	int "System tick frequency (in ticks/second)"
826	default 100 if QEMU_TARGET || SOC_POSIX
827	default 10000 if TICKLESS_KERNEL
828	default 100
829	help
830	  This option specifies the nominal frequency of the system clock in Hz.
831
832	  For asynchronous timekeeping, the kernel defines a "ticks" concept. A
833	  "tick" is the internal count in which the kernel does all its internal
834	  uptime and timeout bookkeeping. Interrupts are expected to be delivered
835	  on tick boundaries to the extent practical, and no fractional ticks
836	  are tracked.
837
838	  The choice of tick rate is configurable by this option. Also the number
839	  of cycles per tick should be chosen so that 1 millisecond is exactly
840	  represented by an integral number of ticks. Defaults on most hardware
841	  platforms (ones that support setting arbitrary interrupt timeouts) are
842	  expected to be in the range of 10 kHz, with software emulation
843	  platforms and legacy drivers using a more traditional 100 Hz value.
844
845	  Note that when available and enabled, in "tickless" mode
846	  this config variable specifies the minimum available timing
847	  granularity, not necessarily the number or frequency of
848	  interrupts delivered to the kernel.
849
850	  A value of 0 completely disables timer support in the kernel.
851
852config SYS_CLOCK_HW_CYCLES_PER_SEC
853	int "System clock's h/w timer frequency"
854	default 0 if TIMER_READS_ITS_FREQUENCY_AT_RUNTIME
855	depends on SYS_CLOCK_EXISTS
856	help
857	  This option specifies the frequency of the hardware timer used for the
858	  system clock (in Hz). This option is set by the SOC's or board's Kconfig file
859	  and the user should generally avoid modifying it via the menu configuration.
860
861config SYS_CLOCK_EXISTS
862	bool "System clock exists and is enabled"
863	default y
864	help
865	  This option specifies that the kernel has timer support.
866
867	  Some device configurations can eliminate significant code if
868	  this is disabled.  Obviously timeout-related APIs will not
869	  work when disabled.
870
871config TIMEOUT_64BIT
872	bool "Store kernel timeouts in 64 bit precision"
873	default y
874	help
875	  When this option is true, the k_ticks_t values passed to
876	  kernel APIs will be a 64 bit quantity, allowing the use of
877	  larger values (and higher precision tick rates) without fear
878	  of overflowing the 32 bit word.  This feature also gates the
879	  availability of absolute timeout values (which require the
880	  extra precision).
881
882config SYS_CLOCK_MAX_TIMEOUT_DAYS
883	int "Max timeout (in days) used in conversions"
884	default 365
885	help
886	  Value is used in the time conversion static inline function to determine
887	  at compile time which algorithm to use. One algorithm is faster, takes
888	  less code but may overflow if multiplication of source and target
889	  frequency exceeds 64 bits. Second algorithm prevents that. Faster
890	  algorithm is selected for conversion if maximum timeout represented in
891	  source frequency domain multiplied by target frequency fits in 64 bits.
892
893config BUSYWAIT_CPU_LOOPS_PER_USEC
894	int "Number of CPU loops per microsecond for crude busy looping"
895	depends on !SYS_CLOCK_EXISTS && !ARCH_HAS_CUSTOM_BUSY_WAIT
896	default 500
897	help
898	  Calibration for crude CPU based busy loop duration. The default
899	  is assuming 1 GHz CPU and 2 cycles per loop. Reality is certainly
900	  much worse but all we want here is a ball-park figure that ought
901	  to be good enough for the purpose of being able to configure out
902	  system timer support. If accuracy is very important then
903	  implementing arch_busy_wait() should be considered.
904
905menu "Security Options"
906
907config REQUIRES_STACK_CANARIES
908	bool
909	help
910	  Hidden option to signal that software stack protection is required.
911
912choice
913	prompt "Stack canaries protection options"
914	optional
915	help
916	  If stack canaries are supported by the compiler, it will emit
917	  extra code that inserts a canary value into the stack frame when
918	  a function is entered and validates this value upon exit.
919	  Stack corruption (such as that caused by buffer overflow) results
920	  in a fatal error condition for the running entity.
921	  Enabling this option, depending on the level chosen, can result in a
922	  significant increase in footprint and a corresponding decrease in performance.
923
924	  If stack canaries are not supported by the compiler an error
925	  will occur at build time.
926
927config STACK_CANARIES
928	bool "Default protection"
929	depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR
930	select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS
931	select REQUIRES_STACK_CANARIES
932	help
933	  This option enables compiler stack canaries in functions that have
934	  vulnerable objects. Generally this means function that call alloca or
935	  have buffers larger than 8 bytes.
936
937config STACK_CANARIES_STRONG
938	bool "Strong protection"
939	depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR
940	select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS
941	select REQUIRES_STACK_CANARIES
942	help
943	  This option enables compiler stack canaries in functions that call alloca,
944	  functions that have local array definition or have references to local
945	  frame addresses.
946
947config STACK_CANARIES_ALL
948	bool "Maximum protection available"
949	depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR
950	select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS
951	select REQUIRES_STACK_CANARIES
952	help
953	  This option enables compiler stack canaries for all functions.
954
955config STACK_CANARIES_EXPLICIT
956	bool "Explicit protection"
957	depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR
958	depends on "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr"
959	select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS
960	select REQUIRES_STACK_CANARIES
961	help
962	  This option enables compiler stack canaries only in functions which have the
963	  stack_protect attribute.
964
965endchoice
966
967if REQUIRES_STACK_CANARIES
968
969config STACK_CANARIES_TLS
970	bool "Stack canaries using thread local storage"
971	depends on THREAD_LOCAL_STORAGE
972	depends on ARCH_HAS_STACK_CANARIES_TLS
973	help
974	  This option enables compiler stack canaries on TLS.
975
976	  Stack canaries will leave in the thread local storage and
977	  each thread will have its own canary. This makes harder
978	  to predict the canary location and value.
979
980	  When enabled this causes an additional performance penalty
981	  during thread creations because it needs a new random value
982	  per thread.
983endif
984
985config EXECUTE_XOR_WRITE
986	bool "W^X for memory partitions"
987	depends on USERSPACE
988	depends on ARCH_HAS_EXECUTABLE_PAGE_BIT
989	default y
990	help
991	  When enabled, will enforce that a writable page isn't executable
992	  and vice versa.  This might not be acceptable in all scenarios,
993	  so this option is given for those unafraid of shooting themselves
994	  in the foot.
995
996	  If unsure, say Y.
997
998config STACK_POINTER_RANDOM
999	int "Initial stack pointer randomization bounds"
1000	depends on !STACK_GROWS_UP
1001	depends on MULTITHREADING
1002	depends on TEST_RANDOM_GENERATOR || ENTROPY_HAS_DRIVER
1003	default 0
1004	help
1005	  This option performs a limited form of Address Space Layout
1006	  Randomization by offsetting some random value to a thread's
1007	  initial stack pointer upon creation. This hinders some types of
1008	  security attacks by making the location of any given stack frame
1009	  non-deterministic.
1010
1011	  This feature can waste up to the specified size in bytes the stack
1012	  region, which is carved out of the total size of the stack region.
1013	  A reasonable minimum value would be around 100 bytes if this can
1014	  be spared.
1015
1016	  This is currently only implemented for systems whose stack pointers
1017	  grow towards lower memory addresses.
1018
1019config BOUNDS_CHECK_BYPASS_MITIGATION
1020	bool "Bounds check bypass mitigations for speculative execution"
1021	depends on USERSPACE
1022	help
1023	  Untrusted parameters from user mode may be used in system calls to
1024	  index arrays during speculative execution, also known as the Spectre
1025	  V1 vulnerability. When enabled, various macros defined in
1026	  misc/speculation.h will insert fence instructions or other appropriate
1027	  mitigations after bounds checking any array index parameters passed
1028	  in from untrusted sources (user mode threads). When disabled, these
1029	  macros do nothing.
1030
1031config HW_SHADOW_STACK
1032	bool "Use hardware shadow stack mechanism to provide stack protection [EXPERIMENTAL]"
1033	depends on ARCH_HAS_HW_SHADOW_STACK
1034	select EXPERIMENTAL
1035	help
1036	  This option enables the use of hardware shadow stack to provide
1037	  stack protection. When enabled, threads that provide a shadow stack
1038	  will use the hardware shadow stack to store the return address of
1039	  function calls. This will help to protect against return-oriented
1040	  programming (ROP) attacks.
1041
1042	  Currently, not all threads created by the kernel will have a shadow
1043	  stack. Indeed, threads need to manually attach a shadow stack to
1044	  use this feature. See the documentation for more information.
1045
1046config HW_SHADOW_STACK_PERCENTAGE_SIZE
1047	int "Percentage of the stack size used to define shadow stack size"
1048	depends on HW_SHADOW_STACK
1049	default 30
1050	range 0 100
1051	help
1052	  This option specifies the percentage of the stack to be used for
1053	  shadow stack. The value is a percentage of the total stack size.
1054	  The default value is 30%, which means that the shadow stack size
1055	  will be 30% of the stack size, in *addition* to the stack size.
1056	  used for shadow stack. Note that this size is constrained by the
1057	  HW_SHADOW_STACK_MIN_SIZE config option.
1058
1059config HW_SHADOW_STACK_MIN_SIZE
1060	int "Minimum size of the hardware shadow stack"
1061	depends on HW_SHADOW_STACK
1062	default 256
1063	help
1064	  This option specifies the minimum size of the hardware shadow stack,
1065	  in bytes, so that threads that use minimal stack size can still
1066	  have a sensible shadow stack size. The default value is 256 bytes,
1067	  which means that the shadow stack size will be at least 256 bytes,
1068	  even if the percentage defined via HW_SHADOW_STACK_PERCENTAGE_SIZE
1069	  would define a smaller size.
1070
1071config HW_SHADOW_STACK_ALLOW_REUSE
1072	bool "Allow reuse of the shadow stack"
1073	depends on HW_SHADOW_STACK
1074	default y if ZTEST
1075	help
1076	  This option allows the reuse of the shadow stack. This is meant to
1077	  accommodate thread reuse, when the same thread is created again,
1078	  such as done by the test suite. It is not meant to be used to share
1079	  the shadow stack between threads.
1080
1081endmenu
1082
1083rsource "Kconfig.mem_domain"
1084rsource "Kconfig.smp"
1085
1086config TICKLESS_KERNEL
1087	bool "Tickless kernel"
1088	default y if TICKLESS_CAPABLE
1089	depends on TICKLESS_CAPABLE
1090	help
1091	  This option enables a fully event driven kernel. Periodic system
1092	  clock interrupt generation would be stopped at all times.
1093
1094config TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE
1095	bool
1096	default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" || "$(ZEPHYR_TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE)" = "y"
1097	help
1098	  Hidden option to signal that toolchain supports generating code
1099	  with thread local storage.
1100
1101config THREAD_LOCAL_STORAGE
1102	bool "Thread Local Storage (TLS)"
1103	depends on ARCH_HAS_THREAD_LOCAL_STORAGE && TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE
1104	select NEED_LIBC_MEM_PARTITION if (CPU_CORTEX_M && USERSPACE)
1105	help
1106	  This option enables thread local storage (TLS) support in kernel.
1107
1108config KERNEL_WHOLE_ARCHIVE
1109	bool
1110	help
1111	  This option forces every object file in the libkernel.a archive
1112	  to be included, rather than searching the archive for required object files.
1113
1114config TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU
1115	# As of today, we don't know of any toolchains that don't create
1116	# either .ctors or .init_array sections containing initializer
1117	# addresses in a fashion compatible with how Zephyr uses them.
1118	def_bool y
1119
1120config STATIC_INIT_GNU
1121	bool "Support GNU-compatible initializers and constructors"
1122	default y if CPP || NATIVE_LIBRARY || COVERAGE
1123	depends on TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU
1124	depends on !CMAKE_LINKER_GENERATOR
1125	help
1126	  GNU-compatible initialization of static objects. This is required for
1127	  C++ constructor support as well as for initializer functions as
1128	  defined by GNU-compatible toolchains. This increases the size of
1129	  Zephyr binaries by around 24 bytes. If you know your application
1130	  doesn't need any initializers, you can disable this option. The linker
1131	  will emit an error if constructors are needed and this option has been
1132	  disabled.
1133
1134menuconfig BOOTARGS
1135	bool "Support bootargs"
1136	help
1137	  Enables bootargs support and passing them to main().
1138
1139if BOOTARGS
1140config DYNAMIC_BOOTARGS
1141	bool "Support dynamic bootargs"
1142	help
1143	  Enables dynamic bootargs support.
1144
1145config BOOTARGS_STRING
1146	string "static bootargs string"
1147	depends on !DYNAMIC_BOOTARGS
1148	help
1149	  Static bootargs string. It includes argv[0], so if its expected that it
1150	  contains executable name it should be put at the beginning of this string.
1151
1152config BOOTARGS_ARGS_BUFFER_SIZE
1153	int "Size of buffer containing main arguments in bytes"
1154	default 1024
1155	help
1156	  Configures size of buffer containing all arguments passed to main.
1157
1158endif # BOOTARGS
1159
1160endmenu
1161
1162rsource "Kconfig.device"
1163rsource "Kconfig.vm"
1164rsource "Kconfig.init"
1165