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