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(arch_current_thread()) 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 4096 if X86 249 default 1024 if !X86 && !64BIT 250 default 2048 if !X86 && 64BIT 251 help 252 Default stack size (in bytes) for dynamic threads. 253 254config DYNAMIC_THREAD_ALLOC 255 bool "Support heap-allocated thread objects and stacks" 256 help 257 Select this option to enable allocating thread object and 258 thread stacks from the system heap. 259 260 Only use this type of allocation in situations 261 where malloc is permitted. 262 263config DYNAMIC_THREAD_POOL_SIZE 264 int "Number of statically pre-allocated threads" 265 default 0 266 range 0 8192 267 help 268 Pre-allocate a fixed number of thread objects and 269 stacks at build time. 270 271 This type of "dynamic" stack is usually suitable in 272 situations where malloc is not permitted. 273 274choice DYNAMIC_THREAD_PREFER 275 prompt "Preferred dynamic thread allocator" 276 default DYNAMIC_THREAD_PREFER_POOL 277 help 278 If both CONFIG_DYNAMIC_THREAD_ALLOC=y and 279 CONFIG_DYNAMIC_THREAD_POOL_SIZE > 0, then the user may 280 specify the order in which allocation is attempted. 281 282config DYNAMIC_THREAD_PREFER_ALLOC 283 bool "Prefer heap-based allocation" 284 depends on DYNAMIC_THREAD_ALLOC 285 help 286 Select this option to attempt a heap-based allocation 287 prior to any pool-based allocation. 288 289config DYNAMIC_THREAD_PREFER_POOL 290 bool "Prefer pool-based allocation" 291 help 292 Select this option to attempt a pool-based allocation 293 prior to any heap-based allocation. 294 295endchoice # DYNAMIC_THREAD_PREFER 296 297endif # DYNAMIC_THREADS 298 299choice SCHED_ALGORITHM 300 prompt "Scheduler priority queue algorithm" 301 default SCHED_DUMB 302 help 303 The kernel can be built with several choices for the 304 ready queue implementation, offering different choices between 305 code size, constant factor runtime overhead and performance 306 scaling when many threads are added. 307 308config SCHED_DUMB 309 bool "Simple linked-list ready queue" 310 help 311 When selected, the scheduler ready queue will be implemented 312 as a simple unordered list, with very fast constant time 313 performance for single threads and very low code size. 314 Choose this on systems with constrained code size that will 315 never see more than a small number (3, maybe) of runnable 316 threads in the queue at any given time. On most platforms 317 (that are not otherwise using the red/black tree) this 318 results in a savings of ~2k of code size. 319 320config SCHED_SCALABLE 321 bool "Red/black tree ready queue" 322 help 323 When selected, the scheduler ready queue will be implemented 324 as a red/black tree. This has rather slower constant-time 325 insertion and removal overhead, and on most platforms (that 326 are not otherwise using the rbtree somewhere) requires an 327 extra ~2kb of code. But the resulting behavior will scale 328 cleanly and quickly into the many thousands of threads. Use 329 this on platforms where you may have many threads (very 330 roughly: more than 20 or so) marked as runnable at a given 331 time. Most applications don't want this. 332 333config SCHED_MULTIQ 334 bool "Traditional multi-queue ready queue" 335 depends on !SCHED_DEADLINE 336 help 337 When selected, the scheduler ready queue will be implemented 338 as the classic/textbook array of lists, one per priority. 339 This corresponds to the scheduler algorithm used in Zephyr 340 versions prior to 1.12. It incurs only a tiny code size 341 overhead vs. the "dumb" scheduler and runs in O(1) time 342 in almost all circumstances with very low constant factor. 343 But it requires a fairly large RAM budget to store those list 344 heads, and the limited features make it incompatible with 345 features like deadline scheduling that need to sort threads 346 more finely, and SMP affinity which need to traverse the list 347 of threads. Typical applications with small numbers of runnable 348 threads probably want the DUMB scheduler. 349 350endchoice # SCHED_ALGORITHM 351 352choice WAITQ_ALGORITHM 353 prompt "Wait queue priority algorithm" 354 default WAITQ_DUMB 355 help 356 The wait_q abstraction used in IPC primitives to pend 357 threads for later wakeup shares the same backend data 358 structure choices as the scheduler, and can use the same 359 options. 360 361config WAITQ_SCALABLE 362 bool "Use scalable wait_q implementation" 363 help 364 When selected, the wait_q will be implemented with a 365 balanced tree. Choose this if you expect to have many 366 threads waiting on individual primitives. There is a ~2kb 367 code size increase over WAITQ_DUMB (which may be shared with 368 SCHED_SCALABLE) if the rbtree is not used elsewhere in the 369 application, and pend/unpend operations on "small" queues 370 will be somewhat slower (though this is not generally a 371 performance path). 372 373config WAITQ_DUMB 374 bool "Simple linked-list wait_q" 375 help 376 When selected, the wait_q will be implemented with a 377 doubly-linked list. Choose this if you expect to have only 378 a few threads blocked on any single IPC primitive. 379 380endchoice # WAITQ_ALGORITHM 381 382menu "Misc Kernel related options" 383config LIBC_ERRNO 384 bool 385 help 386 Use external libc errno, not the internal one. This eliminates any 387 locally allocated errno storage and usage. 388 389config ERRNO 390 bool "Errno support" 391 default y 392 help 393 Enable per-thread errno in the kernel. Application and library code must 394 include errno.h provided by the C library (libc) to use the errno 395 symbol. The C library must access the per-thread errno via the 396 z_errno() symbol. 397 398config ERRNO_IN_TLS 399 bool "Store errno in thread local storage (TLS)" 400 depends on ERRNO && THREAD_LOCAL_STORAGE && !LIBC_ERRNO 401 default y 402 help 403 Use thread local storage to store errno instead of storing it in 404 the kernel thread struct. This avoids a syscall if userspace is enabled. 405 406config CURRENT_THREAD_USE_NO_TLS 407 bool 408 help 409 Hidden symbol to not use thread local storage to store current 410 thread. 411 412config CURRENT_THREAD_USE_TLS 413 bool "Store current thread in thread local storage (TLS)" 414 depends on THREAD_LOCAL_STORAGE && !CURRENT_THREAD_USE_NO_TLS 415 default y 416 help 417 Use thread local storage to store the current thread. This avoids a 418 syscall if userspace is enabled. 419 420endmenu 421 422menu "Kernel Debugging and Metrics" 423 424config INIT_STACKS 425 bool "Initialize stack areas" 426 help 427 This option instructs the kernel to initialize stack areas with a 428 known value (0xaa) before they are first used, so that the high 429 water mark can be easily determined. This applies to the stack areas 430 for threads, as well as to the interrupt stack. 431 432config SKIP_BSS_CLEAR 433 bool 434 help 435 This option disables software .bss section zeroing during Zephyr 436 initialization. Such boot-time optimization could be used for 437 platforms where .bss section is zeroed-out externally. 438 Please pay attention that when this option is enabled 439 the responsibility for .bss zeroing in all possible scenarios 440 (mind e.g. SW reset) is delegated to the external SW or HW. 441 442config BOOT_BANNER 443 bool "Boot banner" 444 default y 445 select PRINTK 446 select EARLY_CONSOLE 447 help 448 This option outputs a banner to the console device during boot up. 449 450config BOOT_BANNER_STRING 451 string "Boot banner string" 452 depends on BOOT_BANNER 453 default "Booting Zephyr OS build" 454 help 455 Use this option to set the boot banner. 456 457config BOOT_DELAY 458 int "Boot delay in milliseconds" 459 depends on MULTITHREADING 460 default 0 461 help 462 This option delays bootup for the specified amount of 463 milliseconds. This is used to allow serial ports to get ready 464 before starting to print information on them during boot, as 465 some systems might boot to fast for a receiving endpoint to 466 detect the new USB serial bus, enumerate it and get ready to 467 receive before it actually gets data. A similar effect can be 468 achieved by waiting for DCD on the serial port--however, not 469 all serial ports have DCD. 470 471config BOOT_CLEAR_SCREEN 472 bool "Clear screen" 473 help 474 Use this option to clear the screen before printing anything else. 475 Using a VT100 enabled terminal on the client side is required for this to work. 476 477config THREAD_MONITOR 478 bool "Thread monitoring" 479 help 480 This option instructs the kernel to maintain a list of all threads 481 (excluding those that have not yet started or have already 482 terminated). 483 484config THREAD_NAME 485 bool "Thread name" 486 help 487 This option allows to set a name for a thread. 488 489config THREAD_MAX_NAME_LEN 490 int "Max length of a thread name" 491 default 32 492 default 64 if ZTEST 493 range 8 128 494 depends on THREAD_NAME 495 help 496 Thread names get stored in the k_thread struct. Indicate the max 497 name length, including the terminating NULL byte. Reduce this value 498 to conserve memory. 499 500config INSTRUMENT_THREAD_SWITCHING 501 bool 502 503menuconfig THREAD_RUNTIME_STATS 504 bool "Thread runtime statistics" 505 help 506 Gather thread runtime statistics. 507 508 For example: 509 - Thread total execution cycles 510 - System total execution cycles 511 512if THREAD_RUNTIME_STATS 513 514config THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS 515 bool "Use timing functions to gather statistics" 516 select TIMING_FUNCTIONS_NEED_AT_BOOT 517 help 518 Use timing functions to gather thread runtime statistics. 519 520 Note that timing functions may use a different timer than 521 the default timer for OS timekeeping. 522 523config SCHED_THREAD_USAGE 524 bool "Collect thread runtime usage" 525 default y 526 select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH 527 help 528 Collect thread runtime info at context switch time 529 530config SCHED_THREAD_USAGE_ANALYSIS 531 bool "Analyze the collected thread runtime usage statistics" 532 default n 533 depends on SCHED_THREAD_USAGE 534 select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH 535 help 536 Collect additional timing information related to thread scheduling 537 for analysis purposes. This includes the total time that a thread 538 has been scheduled, the longest time for which it was scheduled and 539 others. 540 541config SCHED_THREAD_USAGE_ALL 542 bool "Collect total system runtime usage" 543 default y if SCHED_THREAD_USAGE 544 depends on SCHED_THREAD_USAGE 545 help 546 Maintain a sum of all non-idle thread cycle usage. 547 548config SCHED_THREAD_USAGE_AUTO_ENABLE 549 bool "Automatically enable runtime usage statistics" 550 default y 551 depends on SCHED_THREAD_USAGE 552 help 553 When set, this option automatically enables the gathering of both 554 the thread and CPU usage statistics. 555 556endif # THREAD_RUNTIME_STATS 557 558endmenu 559 560rsource "Kconfig.obj_core" 561 562menu "System Work Queue Options" 563config SYSTEM_WORKQUEUE_STACK_SIZE 564 int "System workqueue stack size" 565 default 4096 if COVERAGE_GCOV 566 default 2560 if WIFI_NM_WPA_SUPPLICANT 567 default 1024 568 569config SYSTEM_WORKQUEUE_PRIORITY 570 int "System workqueue priority" 571 default -2 if COOP_ENABLED && !PREEMPT_ENABLED 572 default 0 if !COOP_ENABLED 573 default -1 574 help 575 By default, system work queue priority is the lowest cooperative 576 priority. This means that any work handler, once started, won't 577 be preempted by any other thread until finished. 578 579config SYSTEM_WORKQUEUE_NO_YIELD 580 bool "Select whether system work queue yields" 581 help 582 By default, the system work queue yields between each work item, to 583 prevent other threads from being starved. Selecting this removes 584 this yield, which may be useful if the work queue thread is 585 cooperative and a sequence of work items is expected to complete 586 without yielding. 587 588endmenu 589 590menu "Barrier Operations" 591config BARRIER_OPERATIONS_BUILTIN 592 bool 593 help 594 Use the compiler builtin functions for barrier operations. This is 595 the preferred method. However, support for all arches in GCC is 596 incomplete. 597 598config BARRIER_OPERATIONS_ARCH 599 bool 600 help 601 Use when there isn't support for compiler built-ins, but you have 602 written optimized assembly code under arch/ which implements these. 603endmenu 604 605menu "Atomic Operations" 606config ATOMIC_OPERATIONS_BUILTIN 607 bool 608 help 609 Use the compiler builtin functions for atomic operations. This is 610 the preferred method. However, support for all arches in GCC is 611 incomplete. 612 613config ATOMIC_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. 618 619config ATOMIC_OPERATIONS_C 620 bool 621 help 622 Use atomic operations routines that are implemented entirely 623 in C by locking interrupts. Selected by architectures which either 624 do not have support for atomic operations in their instruction 625 set, or haven't been implemented yet during bring-up, and also 626 the compiler does not have support for the atomic __sync_* builtins. 627endmenu 628 629menu "Timer API Options" 630 631config TIMESLICING 632 bool "Thread time slicing" 633 default y 634 depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0) 635 help 636 This option enables time slicing between preemptible threads of 637 equal priority. 638 639config TIMESLICE_SIZE 640 int "Time slice size (in ms)" 641 default 0 642 range 0 $(INT32_MAX) 643 depends on TIMESLICING 644 help 645 This option specifies the maximum amount of time a thread can execute 646 before other threads of equal priority are given an opportunity to run. 647 A time slice size of zero means "no limit" (i.e. an infinitely large 648 time slice). 649 650config TIMESLICE_PRIORITY 651 int "Time slicing thread priority ceiling" 652 default 0 653 range 0 NUM_PREEMPT_PRIORITIES 654 depends on TIMESLICING 655 help 656 This option specifies the thread priority level at which time slicing 657 takes effect; threads having a higher priority than this ceiling are 658 not subject to time slicing. 659 660config TIMESLICE_PER_THREAD 661 bool "Support per-thread timeslice values" 662 depends on TIMESLICING 663 help 664 When set, this enables an API for setting timeslice values on 665 a per-thread basis, with an application callback invoked when 666 a thread reaches the end of its timeslice. 667 668endmenu 669 670menu "Other Kernel Object Options" 671 672config POLL 673 bool "Async I/O Framework" 674 help 675 Asynchronous notification framework. Enable the k_poll() and 676 k_poll_signal_raise() APIs. The former can wait on multiple events 677 concurrently, which can be either directly triggered or triggered by 678 the availability of some kernel objects (semaphores and FIFOs). 679 680config MEM_SLAB_POINTER_VALIDATE 681 bool "Validate the memory slab pointer when allocating or freeing" 682 default ASSERT 683 help 684 This enables additional runtime checks to validate the memory slab 685 pointer during when allocating or freeing a memory slab. 686 687config MEM_SLAB_TRACE_MAX_UTILIZATION 688 bool "Getting maximum slab utilization" 689 help 690 This adds variable to the k_mem_slab structure to hold 691 maximum utilization of the slab. 692 693config NUM_MBOX_ASYNC_MSGS 694 int "Maximum number of in-flight asynchronous mailbox messages" 695 default 10 696 help 697 This option specifies the total number of asynchronous mailbox 698 messages that can exist simultaneously, across all mailboxes 699 in the system. 700 701 Setting this option to 0 disables support for asynchronous 702 mailbox messages. 703 704config EVENTS 705 bool "Event objects" 706 help 707 This option enables event objects. Threads may wait on event 708 objects for specific events, but both threads and ISRs may deliver 709 events to event objects. 710 711 Note that setting this option slightly increases the size of the 712 thread structure. 713 714config PIPES 715 bool "Pipe objects" 716 help 717 This option enables kernel pipes. A pipe is a kernel object that 718 allows a thread to send a byte stream to another thread. Pipes can 719 be used to synchronously transfer chunks of data in whole or in part. 720 721 Note that setting this option slightly increases the size of the 722 thread structure. 723 724config KERNEL_MEM_POOL 725 bool "Use Kernel Memory Pool" 726 default y 727 help 728 Enable the use of kernel memory pool. 729 730 Say y if unsure. 731 732if KERNEL_MEM_POOL 733 734config HEAP_MEM_POOL_SIZE 735 int "Heap memory pool size (in bytes)" 736 default 0 737 help 738 This option specifies the size of the heap memory pool used when 739 dynamically allocating memory using k_malloc(). The maximum size of 740 the memory pool is only limited to available memory. If subsystems 741 specify HEAP_MEM_POOL_ADD_SIZE_* options, these will be added together 742 and the sum will be compared to the HEAP_MEM_POOL_SIZE value. 743 If the sum is greater than the HEAP_MEM_POOL_SIZE option (even if this 744 has the default 0 value), then the actual heap size will be rounded up 745 to the sum of the individual requirements (unless the 746 HEAP_MEM_POOL_IGNORE_MIN option is enabled). If the final value, after 747 considering both this option as well as sum of the custom 748 requirements, ends up being zero, then no system heap will be 749 available. 750 751config HEAP_MEM_POOL_IGNORE_MIN 752 bool "Ignore the minimum heap memory pool requirement" 753 help 754 This option can be set to force setting a smaller heap memory pool 755 size than what's specified by enabled subsystems. This can be useful 756 when optimizing memory usage and a more precise minimum heap size 757 is known for a given application. 758 759endif # KERNEL_MEM_POOL 760 761endmenu 762 763config SWAP_NONATOMIC 764 bool 765 help 766 On some architectures, the _Swap() primitive cannot be made 767 atomic with respect to the irq_lock being released. That 768 is, interrupts may be received between the entry to _Swap 769 and the completion of the context switch. There are a 770 handful of workaround cases in the kernel that need to be 771 enabled when this is true. Currently, this only happens on 772 ARM when the PendSV exception priority sits below that of 773 Zephyr-handled interrupts. 774 775config ARCH_HAS_THREAD_NAME_HOOK 776 bool 777 help 778 The architecture provides a hook to handle thread name changes beyond 779 just storing it in the kernel structure. 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 REQUIRES_STACK_CANARIES 873 bool 874 help 875 Hidden option to signal that software stack protection is required. 876 877choice 878 prompt "Stack canaries protection options" 879 optional 880 help 881 If stack canaries are supported by the compiler, it will emit 882 extra code that inserts a canary value into the stack frame when 883 a function is entered and validates this value upon exit. 884 Stack corruption (such as that caused by buffer overflow) results 885 in a fatal error condition for the running entity. 886 Enabling this option, depending on the level chosen, can result in a 887 significant increase in footprint and a corresponding decrease in performance. 888 889 If stack canaries are not supported by the compiler an error 890 will occur at build time. 891 892config STACK_CANARIES 893 bool "Default protection" 894 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 895 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 896 select REQUIRES_STACK_CANARIES 897 help 898 This option enables compiler stack canaries in functions that have 899 vulnerable objects. Generally this means function that call alloca or 900 have buffers larger than 8 bytes. 901 902config STACK_CANARIES_STRONG 903 bool "Strong protection" 904 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 905 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 906 select REQUIRES_STACK_CANARIES 907 help 908 This option enables compiler stack canaries in functions that call alloca, 909 functions that have local array definitiion or have references to local 910 frame addresses. 911 912config STACK_CANARIES_ALL 913 bool "Maximum protection available" 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 for all functions. 919 920config STACK_CANARIES_EXPLICIT 921 bool "Explicit protection" 922 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 923 depends on "${ZEPHYR_TOOLCHAIN_VARIANT}" = "zephyr" 924 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 925 select REQUIRES_STACK_CANARIES 926 help 927 This option enables compiler stack canaries only in functions which have the 928 stack_protect attribute. 929 930endchoice 931 932if REQUIRES_STACK_CANARIES 933 934config STACK_CANARIES_TLS 935 bool "Stack canaries using thread local storage" 936 depends on THREAD_LOCAL_STORAGE 937 depends on ARCH_HAS_STACK_CANARIES_TLS 938 help 939 This option enables compiler stack canaries on TLS. 940 941 Stack canaries will leave in the thread local storage and 942 each thread will have its own canary. This makes harder 943 to predict the canary location and value. 944 945 When enabled this causes an additional performance penalty 946 during thread creations because it needs a new random value 947 per thread. 948endif 949 950config EXECUTE_XOR_WRITE 951 bool "W^X for memory partitions" 952 depends on USERSPACE 953 depends on ARCH_HAS_EXECUTABLE_PAGE_BIT 954 default y 955 help 956 When enabled, will enforce that a writable page isn't executable 957 and vice versa. This might not be acceptable in all scenarios, 958 so this option is given for those unafraid of shooting themselves 959 in the foot. 960 961 If unsure, say Y. 962 963config STACK_POINTER_RANDOM 964 int "Initial stack pointer randomization bounds" 965 depends on !STACK_GROWS_UP 966 depends on MULTITHREADING 967 depends on TEST_RANDOM_GENERATOR || ENTROPY_HAS_DRIVER 968 default 0 969 help 970 This option performs a limited form of Address Space Layout 971 Randomization by offsetting some random value to a thread's 972 initial stack pointer upon creation. This hinders some types of 973 security attacks by making the location of any given stack frame 974 non-deterministic. 975 976 This feature can waste up to the specified size in bytes the stack 977 region, which is carved out of the total size of the stack region. 978 A reasonable minimum value would be around 100 bytes if this can 979 be spared. 980 981 This is currently only implemented for systems whose stack pointers 982 grow towards lower memory addresses. 983 984config BOUNDS_CHECK_BYPASS_MITIGATION 985 bool "Bounds check bypass mitigations for speculative execution" 986 depends on USERSPACE 987 help 988 Untrusted parameters from user mode may be used in system calls to 989 index arrays during speculative execution, also known as the Spectre 990 V1 vulnerability. When enabled, various macros defined in 991 misc/speculation.h will insert fence instructions or other appropriate 992 mitigations after bounds checking any array index parameters passed 993 in from untrusted sources (user mode threads). When disabled, these 994 macros do nothing. 995endmenu 996 997rsource "Kconfig.mem_domain" 998rsource "Kconfig.smp" 999 1000config TICKLESS_KERNEL 1001 bool "Tickless kernel" 1002 default y if TICKLESS_CAPABLE 1003 depends on TICKLESS_CAPABLE 1004 help 1005 This option enables a fully event driven kernel. Periodic system 1006 clock interrupt generation would be stopped at all times. 1007 1008config TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 1009 bool 1010 default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" || "$(ZEPHYR_TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE)" = "y" 1011 help 1012 Hidden option to signal that toolchain supports generating code 1013 with thread local storage. 1014 1015config THREAD_LOCAL_STORAGE 1016 bool "Thread Local Storage (TLS)" 1017 depends on ARCH_HAS_THREAD_LOCAL_STORAGE && TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 1018 select NEED_LIBC_MEM_PARTITION if (CPU_CORTEX_M && USERSPACE) 1019 help 1020 This option enables thread local storage (TLS) support in kernel. 1021 1022config KERNEL_WHOLE_ARCHIVE 1023 bool 1024 help 1025 This option forces every object file in the libkernel.a archive 1026 to be included, rather than searching the archive for required object files. 1027 1028config TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU 1029 # As of today only ARC MWDT toolchain doesn't support GNU-compatible 1030 # initialization of static objects, new toolchains can be added 1031 # here if required. 1032 def_bool "$(ZEPHYR_TOOLCHAIN_VARIANT)" != "arcmwdt" 1033 1034config STATIC_INIT_GNU 1035 bool "Support GNU-compatible initializers and constructors" 1036 default y if CPP || NATIVE_LIBRARY || COVERAGE 1037 depends on TOOLCHAIN_SUPPORTS_STATIC_INIT_GNU 1038 depends on !CMAKE_LINKER_GENERATOR 1039 help 1040 GNU-compatible initialization of static objects. This is required for 1041 C++ constructor support as well as for initializer functions as 1042 defined by GNU-compatible toolchains. This increases the size 1043 of Zephyr binaries by around 100 bytes. If you know your 1044 application doesn't need any initializers, you can disable this 1045 option. 1046 The ARC MWDT toolchain, does not support or use this setting, 1047 and has instead separate C++ constructor initialization code. 1048 Note the option CMAKE_LINKER_GENERATOR does not yet support this feature 1049 or CPP. 1050 1051config BOOTARGS 1052 bool "Support bootargs" 1053 help 1054 Enables bootargs support and passing them to main(). 1055 1056config DYNAMIC_BOOTARGS 1057 bool "Support dynamic bootargs" 1058 depends on BOOTARGS && (MULTIBOOT_INFO || BUILD_OUTPUT_EFI) 1059 help 1060 Enables dynamic bootargs support. 1061 1062config BOOTARGS_STRING 1063 string "static bootargs string" 1064 depends on BOOTARGS && !DYNAMIC_BOOTARGS 1065 help 1066 Static bootargs string. It includes argv[0], so if its expected that it 1067 contains executable name it should be put at the beginning of this string. 1068 1069config BOOTARGS_ARGS_BUFFER_SIZE 1070 int "Size of buffer containing main arguments in bytes" 1071 default 1024 1072 depends on BOOTARGS 1073 help 1074 Configures size of buffer containing all arguments passed to main. 1075 1076endmenu 1077 1078rsource "Kconfig.device" 1079rsource "Kconfig.vm" 1080rsource "Kconfig.init" 1081
