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 || NIOS2) 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 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 573endmenu 574 575rsource "Kconfig.obj_core" 576 577menu "System Work Queue Options" 578config SYSTEM_WORKQUEUE_STACK_SIZE 579 int "System workqueue stack size" 580 default 4096 if COVERAGE_GCOV 581 default 2560 if WIFI_NM_WPA_SUPPLICANT 582 default 1024 583 584config SYSTEM_WORKQUEUE_PRIORITY 585 int "System workqueue priority" 586 default -2 if COOP_ENABLED && !PREEMPT_ENABLED 587 default 0 if !COOP_ENABLED 588 default -1 589 help 590 By default, system work queue priority is the lowest cooperative 591 priority. This means that any work handler, once started, won't 592 be preempted by any other thread until finished. 593 594config SYSTEM_WORKQUEUE_NO_YIELD 595 bool "Select whether system work queue yields" 596 help 597 By default, the system work queue yields between each work item, to 598 prevent other threads from being starved. Selecting this removes 599 this yield, which may be useful if the work queue thread is 600 cooperative and a sequence of work items is expected to complete 601 without yielding. 602 603endmenu 604 605menu "Barrier Operations" 606config BARRIER_OPERATIONS_BUILTIN 607 bool 608 help 609 Use the compiler builtin functions for barrier operations. This is 610 the preferred method. However, support for all arches in GCC is 611 incomplete. 612 613config BARRIER_OPERATIONS_ARCH 614 bool 615 help 616 Use when there isn't support for compiler built-ins, but you have 617 written optimized assembly code under arch/ which implements these. 618endmenu 619 620menu "Atomic Operations" 621config ATOMIC_OPERATIONS_BUILTIN 622 bool 623 help 624 Use the compiler builtin functions for atomic operations. This is 625 the preferred method. However, support for all arches in GCC is 626 incomplete. 627 628config ATOMIC_OPERATIONS_ARCH 629 bool 630 help 631 Use when there isn't support for compiler built-ins, but you have 632 written optimized assembly code under arch/ which implements these. 633 634config ATOMIC_OPERATIONS_C 635 bool 636 help 637 Use atomic operations routines that are implemented entirely 638 in C by locking interrupts. Selected by architectures which either 639 do not have support for atomic operations in their instruction 640 set, or haven't been implemented yet during bring-up, and also 641 the compiler does not have support for the atomic __sync_* builtins. 642endmenu 643 644menu "Timer API Options" 645 646config TIMESLICING 647 bool "Thread time slicing" 648 default y 649 depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0) 650 help 651 This option enables time slicing between preemptible threads of 652 equal priority. 653 654config TIMESLICE_SIZE 655 int "Time slice size (in ms)" 656 default 0 657 range 0 $(INT32_MAX) 658 depends on TIMESLICING 659 help 660 This option specifies the maximum amount of time a thread can execute 661 before other threads of equal priority are given an opportunity to run. 662 A time slice size of zero means "no limit" (i.e. an infinitely large 663 time slice). 664 665config TIMESLICE_PRIORITY 666 int "Time slicing thread priority ceiling" 667 default 0 668 range 0 NUM_PREEMPT_PRIORITIES 669 depends on TIMESLICING 670 help 671 This option specifies the thread priority level at which time slicing 672 takes effect; threads having a higher priority than this ceiling are 673 not subject to time slicing. 674 675config TIMESLICE_PER_THREAD 676 bool "Support per-thread timeslice values" 677 depends on TIMESLICING 678 help 679 When set, this enables an API for setting timeslice values on 680 a per-thread basis, with an application callback invoked when 681 a thread reaches the end of its timeslice. 682 683endmenu 684 685menu "Other Kernel Object Options" 686 687config POLL 688 bool "Async I/O Framework" 689 help 690 Asynchronous notification framework. Enable the k_poll() and 691 k_poll_signal_raise() APIs. The former can wait on multiple events 692 concurrently, which can be either directly triggered or triggered by 693 the availability of some kernel objects (semaphores and FIFOs). 694 695config MEM_SLAB_POINTER_VALIDATE 696 bool "Validate the memory slab pointer when allocating or freeing" 697 default ASSERT 698 help 699 This enables additional runtime checks to validate the memory slab 700 pointer during when allocating or freeing a memory slab. 701 702config MEM_SLAB_TRACE_MAX_UTILIZATION 703 bool "Getting maximum slab utilization" 704 help 705 This adds variable to the k_mem_slab structure to hold 706 maximum utilization of the slab. 707 708config NUM_MBOX_ASYNC_MSGS 709 int "Maximum number of in-flight asynchronous mailbox messages" 710 default 10 711 help 712 This option specifies the total number of asynchronous mailbox 713 messages that can exist simultaneously, across all mailboxes 714 in the system. 715 716 Setting this option to 0 disables support for asynchronous 717 mailbox messages. 718 719config EVENTS 720 bool "Event objects" 721 help 722 This option enables event objects. Threads may wait on event 723 objects for specific events, but both threads and ISRs may deliver 724 events to event objects. 725 726 Note that setting this option slightly increases the size of the 727 thread structure. 728 729config PIPES 730 bool "Pipe objects" 731 select DEPRECATED 732 help 733 This option enables kernel pipes. A pipe is a kernel object that 734 allows a thread to send a byte stream to another thread. Pipes can 735 be used to synchronously transfer chunks of data in whole or in part. 736 737 Note that setting this option slightly increases the size of the 738 thread structure. 739 This Kconfig is deprecated and will be removed, by disabling this 740 kconfig another implementation of k_pipe will be available when 741 CONFIG_MULTITHREADING is enabled. 742 743config KERNEL_MEM_POOL 744 bool "Use Kernel Memory Pool" 745 default y 746 help 747 Enable the use of kernel memory pool. 748 749 Say y if unsure. 750 751if KERNEL_MEM_POOL 752 753config HEAP_MEM_POOL_SIZE 754 int "Heap memory pool size (in bytes)" 755 default 0 756 help 757 This option specifies the size of the heap memory pool used when 758 dynamically allocating memory using k_malloc(). The maximum size of 759 the memory pool is only limited to available memory. If subsystems 760 specify HEAP_MEM_POOL_ADD_SIZE_* options, these will be added together 761 and the sum will be compared to the HEAP_MEM_POOL_SIZE value. 762 If the sum is greater than the HEAP_MEM_POOL_SIZE option (even if this 763 has the default 0 value), then the actual heap size will be rounded up 764 to the sum of the individual requirements (unless the 765 HEAP_MEM_POOL_IGNORE_MIN option is enabled). If the final value, after 766 considering both this option as well as sum of the custom 767 requirements, ends up being zero, then no system heap will be 768 available. 769 770config HEAP_MEM_POOL_IGNORE_MIN 771 bool "Ignore the minimum heap memory pool requirement" 772 help 773 This option can be set to force setting a smaller heap memory pool 774 size than what's specified by enabled subsystems. This can be useful 775 when optimizing memory usage and a more precise minimum heap size 776 is known for a given application. 777 778endif # KERNEL_MEM_POOL 779 780endmenu 781 782config SWAP_NONATOMIC 783 bool 784 help 785 On some architectures, the _Swap() primitive cannot be made 786 atomic with respect to the irq_lock being released. That 787 is, interrupts may be received between the entry to _Swap 788 and the completion of the context switch. There are a 789 handful of workaround cases in the kernel that need to be 790 enabled when this is true. Currently, this only happens on 791 ARM when the PendSV exception priority sits below that of 792 Zephyr-handled interrupts. 793 794config ARCH_HAS_THREAD_NAME_HOOK 795 bool 796 help 797 The architecture provides a hook to handle thread name changes beyond 798 just storing it in the kernel structure. 799 800config SYS_CLOCK_TICKS_PER_SEC 801 int "System tick frequency (in ticks/second)" 802 default 100 if QEMU_TARGET || SOC_POSIX 803 default 10000 if TICKLESS_KERNEL 804 default 100 805 help 806 This option specifies the nominal frequency of the system clock in Hz. 807 808 For asynchronous timekeeping, the kernel defines a "ticks" concept. A 809 "tick" is the internal count in which the kernel does all its internal 810 uptime and timeout bookkeeping. Interrupts are expected to be delivered 811 on tick boundaries to the extent practical, and no fractional ticks 812 are tracked. 813 814 The choice of tick rate is configurable by this option. Also the number 815 of cycles per tick should be chosen so that 1 millisecond is exactly 816 represented by an integral number of ticks. Defaults on most hardware 817 platforms (ones that support setting arbitrary interrupt timeouts) are 818 expected to be in the range of 10 kHz, with software emulation 819 platforms and legacy drivers using a more traditional 100 Hz value. 820 821 Note that when available and enabled, in "tickless" mode 822 this config variable specifies the minimum available timing 823 granularity, not necessarily the number or frequency of 824 interrupts delivered to the kernel. 825 826 A value of 0 completely disables timer support in the kernel. 827 828config SYS_CLOCK_HW_CYCLES_PER_SEC 829 int "System clock's h/w timer frequency" 830 default 0 if TIMER_READS_ITS_FREQUENCY_AT_RUNTIME 831 help 832 This option specifies the frequency of the hardware timer used for the 833 system clock (in Hz). This option is set by the SOC's or board's Kconfig file 834 and the user should generally avoid modifying it via the menu configuration. 835 836config SYS_CLOCK_EXISTS 837 bool "System clock exists and is enabled" 838 default y 839 help 840 This option specifies that the kernel has timer support. 841 842 Some device configurations can eliminate significant code if 843 this is disabled. Obviously timeout-related APIs will not 844 work when disabled. 845 846config TIMEOUT_64BIT 847 bool "Store kernel timeouts in 64 bit precision" 848 default y 849 help 850 When this option is true, the k_ticks_t values passed to 851 kernel APIs will be a 64 bit quantity, allowing the use of 852 larger values (and higher precision tick rates) without fear 853 of overflowing the 32 bit word. This feature also gates the 854 availability of absolute timeout values (which require the 855 extra precision). 856 857config SYS_CLOCK_MAX_TIMEOUT_DAYS 858 int "Max timeout (in days) used in conversions" 859 default 365 860 help 861 Value is used in the time conversion static inline function to determine 862 at compile time which algorithm to use. One algorithm is faster, takes 863 less code but may overflow if multiplication of source and target 864 frequency exceeds 64 bits. Second algorithm prevents that. Faster 865 algorithm is selected for conversion if maximum timeout represented in 866 source frequency domain multiplied by target frequency fits in 64 bits. 867 868config BUSYWAIT_CPU_LOOPS_PER_USEC 869 int "Number of CPU loops per microsecond for crude busy looping" 870 depends on !SYS_CLOCK_EXISTS && !ARCH_HAS_CUSTOM_BUSY_WAIT 871 default 500 872 help 873 Calibration for crude CPU based busy loop duration. The default 874 is assuming 1 GHz CPU and 2 cycles per loop. Reality is certainly 875 much worse but all we want here is a ball-park figure that ought 876 to be good enough for the purpose of being able to configure out 877 system timer support. If accuracy is very important then 878 implementing arch_busy_wait() should be considered. 879 880config XIP 881 bool "Execute in place" 882 help 883 This option allows the kernel to operate with its text and read-only 884 sections residing in ROM (or similar read-only memory). Not all boards 885 support this option so it must be used with care; you must also 886 supply a linker command file when building your image. Enabling this 887 option increases both the code and data footprint of the image. 888 889 890menu "Security Options" 891 892config REQUIRES_STACK_CANARIES 893 bool 894 help 895 Hidden option to signal that software stack protection is required. 896 897choice 898 prompt "Stack canaries protection options" 899 optional 900 help 901 If stack canaries are supported by the compiler, it will emit 902 extra code that inserts a canary value into the stack frame when 903 a function is entered and validates this value upon exit. 904 Stack corruption (such as that caused by buffer overflow) results 905 in a fatal error condition for the running entity. 906 Enabling this option, depending on the level chosen, can result in a 907 significant increase in footprint and a corresponding decrease in performance. 908 909 If stack canaries are not supported by the compiler an error 910 will occur at build time. 911 912config STACK_CANARIES 913 bool "Default protection" 914 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 915 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 916 select REQUIRES_STACK_CANARIES 917 help 918 This option enables compiler stack canaries in functions that have 919 vulnerable objects. Generally this means function that call alloca or 920 have buffers larger than 8 bytes. 921 922config STACK_CANARIES_STRONG 923 bool "Strong protection" 924 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 925 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 926 select REQUIRES_STACK_CANARIES 927 help 928 This option enables compiler stack canaries in functions that call alloca, 929 functions that have local array definitiion or have references to local 930 frame addresses. 931 932config STACK_CANARIES_ALL 933 bool "Maximum protection available" 934 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 935 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 936 select REQUIRES_STACK_CANARIES 937 help 938 This option enables compiler stack canaries for all functions. 939 940config STACK_CANARIES_EXPLICIT 941 bool "Explicit protection" 942 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 943 depends on "${ZEPHYR_TOOLCHAIN_VARIANT}" = "zephyr" 944 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 945 select REQUIRES_STACK_CANARIES 946 help 947 This option enables compiler stack canaries only in functions which have the 948 stack_protect attribute. 949 950endchoice 951 952if REQUIRES_STACK_CANARIES 953 954config STACK_CANARIES_TLS 955 bool "Stack canaries using thread local storage" 956 depends on THREAD_LOCAL_STORAGE 957 depends on ARCH_HAS_STACK_CANARIES_TLS 958 help 959 This option enables compiler stack canaries on TLS. 960 961 Stack canaries will leave in the thread local storage and 962 each thread will have its own canary. This makes harder 963 to predict the canary location and value. 964 965 When enabled this causes an additional performance penalty 966 during thread creations because it needs a new random value 967 per thread. 968endif 969 970config EXECUTE_XOR_WRITE 971 bool "W^X for memory partitions" 972 depends on USERSPACE 973 depends on ARCH_HAS_EXECUTABLE_PAGE_BIT 974 default y 975 help 976 When enabled, will enforce that a writable page isn't executable 977 and vice versa. This might not be acceptable in all scenarios, 978 so this option is given for those unafraid of shooting themselves 979 in the foot. 980 981 If unsure, say Y. 982 983config STACK_POINTER_RANDOM 984 int "Initial stack pointer randomization bounds" 985 depends on !STACK_GROWS_UP 986 depends on MULTITHREADING 987 depends on TEST_RANDOM_GENERATOR || ENTROPY_HAS_DRIVER 988 default 0 989 help 990 This option performs a limited form of Address Space Layout 991 Randomization by offsetting some random value to a thread's 992 initial stack pointer upon creation. This hinders some types of 993 security attacks by making the location of any given stack frame 994 non-deterministic. 995 996 This feature can waste up to the specified size in bytes the stack 997 region, which is carved out of the total size of the stack region. 998 A reasonable minimum value would be around 100 bytes if this can 999 be spared. 1000 1001 This is currently only implemented for systems whose stack pointers 1002 grow towards lower memory addresses. 1003 1004config BOUNDS_CHECK_BYPASS_MITIGATION 1005 bool "Bounds check bypass mitigations for speculative execution" 1006 depends on USERSPACE 1007 help 1008 Untrusted parameters from user mode may be used in system calls to 1009 index arrays during speculative execution, also known as the Spectre 1010 V1 vulnerability. When enabled, various macros defined in 1011 misc/speculation.h will insert fence instructions or other appropriate 1012 mitigations after bounds checking any array index parameters passed 1013 in from untrusted sources (user mode threads). When disabled, these 1014 macros do nothing. 1015endmenu 1016 1017rsource "Kconfig.mem_domain" 1018rsource "Kconfig.smp" 1019 1020config TICKLESS_KERNEL 1021 bool "Tickless kernel" 1022 default y if TICKLESS_CAPABLE 1023 depends on TICKLESS_CAPABLE 1024 help 1025 This option enables a fully event driven kernel. Periodic system 1026 clock interrupt generation would be stopped at all times. 1027 1028config TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 1029 bool 1030 default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" || "$(ZEPHYR_TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE)" = "y" 1031 help 1032 Hidden option to signal that toolchain supports generating code 1033 with thread local storage. 1034 1035config THREAD_LOCAL_STORAGE 1036 bool "Thread Local Storage (TLS)" 1037 depends on ARCH_HAS_THREAD_LOCAL_STORAGE && TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 1038 select NEED_LIBC_MEM_PARTITION if (CPU_CORTEX_M && USERSPACE) 1039 help 1040 This option enables thread local storage (TLS) support in kernel. 1041 1042config KERNEL_WHOLE_ARCHIVE 1043 bool 1044 help 1045 This option forces every object file in the libkernel.a archive 1046 to be included, rather than searching the archive for required object files. 1047 1048config TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU 1049 # As of today only ARC MWDT toolchain doesn't support GNU-compatible 1050 # initialization of static objects, new toolchains can be added 1051 # here if required. 1052 def_bool "$(ZEPHYR_TOOLCHAIN_VARIANT)" != "arcmwdt" 1053 1054config STATIC_INIT_GNU 1055 bool "Support GNU-compatible initializers and constructors" 1056 default y if CPP || NATIVE_LIBRARY || COVERAGE 1057 depends on TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU 1058 depends on !CMAKE_LINKER_GENERATOR 1059 help 1060 GNU-compatible initialization of static objects. This is required for 1061 C++ constructor support as well as for initializer functions as 1062 defined by GNU-compatible toolchains. This increases the size 1063 of Zephyr binaries by around 100 bytes. If you know your 1064 application doesn't need any initializers, you can disable this 1065 option. 1066 The ARC MWDT toolchain, does not support or use this setting, 1067 and has instead separate C++ constructor initialization code. 1068 Note the option CMAKE_LINKER_GENERATOR does not yet support this feature 1069 or CPP. 1070 1071config BOOTARGS 1072 bool "Support bootargs" 1073 help 1074 Enables bootargs support and passing them to main(). 1075 1076config DYNAMIC_BOOTARGS 1077 bool "Support dynamic bootargs" 1078 depends on BOOTARGS 1079 help 1080 Enables dynamic bootargs support. 1081 1082config BOOTARGS_STRING 1083 string "static bootargs string" 1084 depends on BOOTARGS && !DYNAMIC_BOOTARGS 1085 help 1086 Static bootargs string. It includes argv[0], so if its expected that it 1087 contains executable name it should be put at the beginning of this string. 1088 1089config BOOTARGS_ARGS_BUFFER_SIZE 1090 int "Size of buffer containing main arguments in bytes" 1091 default 1024 1092 depends on BOOTARGS 1093 help 1094 Configures size of buffer containing all arguments passed to main. 1095 1096endmenu 1097 1098rsource "Kconfig.device" 1099rsource "Kconfig.vm" 1100rsource "Kconfig.init" 1101
