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) 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_CUSTOM_DATA 196 bool "Thread custom data" 197 help 198 This option allows each thread to store 32 bits of custom data, 199 which can be accessed using the k_thread_custom_data_xxx() APIs. 200 201config THREAD_USERSPACE_LOCAL_DATA 202 bool 203 depends on USERSPACE 204 default y if ERRNO && !ERRNO_IN_TLS && !LIBC_ERRNO 205 206config DYNAMIC_THREAD 207 bool "Support for dynamic threads [EXPERIMENTAL]" 208 select EXPERIMENTAL 209 depends on THREAD_STACK_INFO 210 select DYNAMIC_OBJECTS if USERSPACE 211 help 212 Enable support for dynamic threads and stacks. 213 214if DYNAMIC_THREAD 215 216config DYNAMIC_THREAD_STACK_SIZE 217 int "Size of each pre-allocated thread stack" 218 default 1024 if !64BIT 219 default 2048 if 64BIT 220 help 221 Default stack size (in bytes) for dynamic threads. 222 223config DYNAMIC_THREAD_ALLOC 224 bool "Support heap-allocated thread objects and stacks" 225 help 226 Select this option to enable allocating thread object and 227 thread stacks from the system heap. 228 229 Only use this type of allocation in situations 230 where malloc is permitted. 231 232config DYNAMIC_THREAD_POOL_SIZE 233 int "Number of statically pre-allocated threads" 234 default 0 235 range 0 8192 236 help 237 Pre-allocate a fixed number of thread objects and 238 stacks at build time. 239 240 This type of "dynamic" stack is usually suitable in 241 situations where malloc is not permitted. 242 243choice DYNAMIC_THREAD_PREFER 244 prompt "Preferred dynamic thread allocator" 245 default DYNAMIC_THREAD_PREFER_POOL 246 help 247 If both CONFIG_DYNAMIC_THREAD_ALLOC=y and 248 CONFIG_DYNAMIC_THREAD_POOL_SIZE > 0, then the user may 249 specify the order in which allocation is attmpted. 250 251config DYNAMIC_THREAD_PREFER_ALLOC 252 bool "Prefer heap-based allocation" 253 depends on DYNAMIC_THREAD_ALLOC 254 help 255 Select this option to attempt a heap-based allocation 256 prior to any pool-based allocation. 257 258config DYNAMIC_THREAD_PREFER_POOL 259 bool "Prefer pool-based allocation" 260 help 261 Select this option to attempt a pool-based allocation 262 prior to any heap-based allocation. 263 264endchoice # DYNAMIC_THREAD_PREFER 265 266endif # DYNAMIC_THREADS 267 268config LIBC_ERRNO 269 bool 270 help 271 Use external libc errno, not the internal one. This eliminates any 272 locally allocated errno storage and usage. 273 274config ERRNO 275 bool "Errno support" 276 default y 277 help 278 Enable per-thread errno in the kernel. Application and library code must 279 include errno.h provided by the C library (libc) to use the errno 280 symbol. The C library must access the per-thread errno via the 281 z_errno() symbol. 282 283config ERRNO_IN_TLS 284 bool "Store errno in thread local storage (TLS)" 285 depends on ERRNO && THREAD_LOCAL_STORAGE && !LIBC_ERRNO 286 default y 287 help 288 Use thread local storage to store errno instead of storing it in 289 the kernel thread struct. This avoids a syscall if userspace is enabled. 290 291config CURRENT_THREAD_USE_NO_TLS 292 bool 293 help 294 Hidden symbol to not use thread local storage to store current 295 thread. 296 297config CURRENT_THREAD_USE_TLS 298 bool "Store current thread in thread local storage (TLS)" 299 depends on THREAD_LOCAL_STORAGE && !CURRENT_THREAD_USE_NO_TLS 300 default y 301 help 302 Use thread local storage to store the current thread. This avoids a 303 syscall if userspace is enabled. 304 305choice SCHED_ALGORITHM 306 prompt "Scheduler priority queue algorithm" 307 default SCHED_DUMB 308 help 309 The kernel can be built with with several choices for the 310 ready queue implementation, offering different choices between 311 code size, constant factor runtime overhead and performance 312 scaling when many threads are added. 313 314config SCHED_DUMB 315 bool "Simple linked-list ready queue" 316 help 317 When selected, the scheduler ready queue will be implemented 318 as a simple unordered list, with very fast constant time 319 performance for single threads and very low code size. 320 Choose this on systems with constrained code size that will 321 never see more than a small number (3, maybe) of runnable 322 threads in the queue at any given time. On most platforms 323 (that are not otherwise using the red/black tree) this 324 results in a savings of ~2k of code size. 325 326config SCHED_SCALABLE 327 bool "Red/black tree ready queue" 328 help 329 When selected, the scheduler ready queue will be implemented 330 as a red/black tree. This has rather slower constant-time 331 insertion and removal overhead, and on most platforms (that 332 are not otherwise using the rbtree somewhere) requires an 333 extra ~2kb of code. But the resulting behavior will scale 334 cleanly and quickly into the many thousands of threads. Use 335 this on platforms where you may have many threads (very 336 roughly: more than 20 or so) marked as runnable at a given 337 time. Most applications don't want this. 338 339config SCHED_MULTIQ 340 bool "Traditional multi-queue ready queue" 341 depends on !SCHED_DEADLINE 342 help 343 When selected, the scheduler ready queue will be implemented 344 as the classic/textbook array of lists, one per priority 345 (max 32 priorities). This corresponds to the scheduler 346 algorithm used in Zephyr versions prior to 1.12. It incurs 347 only a tiny code size overhead vs. the "dumb" scheduler and 348 runs in O(1) time in almost all circumstances with very low 349 constant factor. But it requires a fairly large RAM budget 350 to store those list heads, and the limited features make it 351 incompatible with features like deadline scheduling that 352 need to sort threads more finely, and SMP affinity which 353 need to traverse the list of threads. Typical applications 354 with small numbers of runnable threads probably want the 355 DUMB scheduler. 356 357endchoice # SCHED_ALGORITHM 358 359choice WAITQ_ALGORITHM 360 prompt "Wait queue priority algorithm" 361 default WAITQ_DUMB 362 help 363 The wait_q abstraction used in IPC primitives to pend 364 threads for later wakeup shares the same backend data 365 structure choices as the scheduler, and can use the same 366 options. 367 368config WAITQ_SCALABLE 369 bool "Use scalable wait_q implementation" 370 help 371 When selected, the wait_q will be implemented with a 372 balanced tree. Choose this if you expect to have many 373 threads waiting on individual primitives. There is a ~2kb 374 code size increase over WAITQ_DUMB (which may be shared with 375 SCHED_SCALABLE) if the rbtree is not used elsewhere in the 376 application, and pend/unpend operations on "small" queues 377 will be somewhat slower (though this is not generally a 378 performance path). 379 380config WAITQ_DUMB 381 bool "Simple linked-list wait_q" 382 help 383 When selected, the wait_q will be implemented with a 384 doubly-linked list. Choose this if you expect to have only 385 a few threads blocked on any single IPC primitive. 386 387endchoice # WAITQ_ALGORITHM 388 389menu "Kernel Debugging and Metrics" 390 391config INIT_STACKS 392 bool "Initialize stack areas" 393 help 394 This option instructs the kernel to initialize stack areas with a 395 known value (0xaa) before they are first used, so that the high 396 water mark can be easily determined. This applies to the stack areas 397 for threads, as well as to the interrupt stack. 398 399config SKIP_BSS_CLEAR 400 bool 401 help 402 This option disables software .bss section zeroing during Zephyr 403 initialization. Such boot-time optimization could be used for 404 platforms where .bss section is zeroed-out externally. 405 Please pay attention that when this option is enabled 406 the responsibility for .bss zeroing in all possible scenarios 407 (mind e.g. SW reset) is delegated to the external SW or HW. 408 409config BOOT_BANNER 410 bool "Boot banner" 411 default y 412 select PRINTK 413 select EARLY_CONSOLE 414 help 415 This option outputs a banner to the console device during boot up. 416 417config BOOT_BANNER_STRING 418 string "Boot banner string" 419 depends on BOOT_BANNER 420 default "Booting Zephyr OS build" 421 help 422 Use this option to set the boot banner. 423 424config BOOT_DELAY 425 int "Boot delay in milliseconds" 426 depends on MULTITHREADING 427 default 0 428 help 429 This option delays bootup for the specified amount of 430 milliseconds. This is used to allow serial ports to get ready 431 before starting to print information on them during boot, as 432 some systems might boot to fast for a receiving endpoint to 433 detect the new USB serial bus, enumerate it and get ready to 434 receive before it actually gets data. A similar effect can be 435 achieved by waiting for DCD on the serial port--however, not 436 all serial ports have DCD. 437 438config THREAD_MONITOR 439 bool "Thread monitoring" 440 help 441 This option instructs the kernel to maintain a list of all threads 442 (excluding those that have not yet started or have already 443 terminated). 444 445config THREAD_NAME 446 bool "Thread name" 447 help 448 This option allows to set a name for a thread. 449 450config THREAD_MAX_NAME_LEN 451 int "Max length of a thread name" 452 default 32 453 default 64 if ZTEST 454 range 8 128 455 depends on THREAD_NAME 456 help 457 Thread names get stored in the k_thread struct. Indicate the max 458 name length, including the terminating NULL byte. Reduce this value 459 to conserve memory. 460 461config INSTRUMENT_THREAD_SWITCHING 462 bool 463 464menuconfig THREAD_RUNTIME_STATS 465 bool "Thread runtime statistics" 466 help 467 Gather thread runtime statistics. 468 469 For example: 470 - Thread total execution cycles 471 - System total execution cycles 472 473if THREAD_RUNTIME_STATS 474 475config THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS 476 bool "Use timing functions to gather statistics" 477 select TIMING_FUNCTIONS_NEED_AT_BOOT 478 help 479 Use timing functions to gather thread runtime statistics. 480 481 Note that timing functions may use a different timer than 482 the default timer for OS timekeeping. 483 484config SCHED_THREAD_USAGE 485 bool "Collect thread runtime usage" 486 default y 487 select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH 488 help 489 Collect thread runtime info at context switch time 490 491config SCHED_THREAD_USAGE_ANALYSIS 492 bool "Analyze the collected thread runtime usage statistics" 493 default n 494 depends on SCHED_THREAD_USAGE 495 select INSTRUMENT_THREAD_SWITCHING if !USE_SWITCH 496 help 497 Collect additional timing information related to thread scheduling 498 for analysis purposes. This includes the total time that a thread 499 has been scheduled, the longest time for which it was scheduled and 500 others. 501 502config SCHED_THREAD_USAGE_ALL 503 bool "Collect total system runtime usage" 504 default y if SCHED_THREAD_USAGE 505 depends on SCHED_THREAD_USAGE 506 help 507 Maintain a sum of all non-idle thread cycle usage. 508 509config SCHED_THREAD_USAGE_AUTO_ENABLE 510 bool "Automatically enable runtime usage statistics" 511 default y 512 depends on SCHED_THREAD_USAGE 513 help 514 When set, this option automatically enables the gathering of both 515 the thread and CPU usage statistics. 516 517endif # THREAD_RUNTIME_STATS 518 519endmenu 520 521menuconfig OBJ_CORE 522 bool "Object core framework" 523 default n 524 help 525 This option enables the object core framework. This will link 526 participating kernel objects and their respective types together 527 in a way that allows them to both have common information stored 528 together and for that information to be easily retrieved by 529 automated means. 530 531if OBJ_CORE 532config OBJ_CORE_CONDVAR 533 bool "Integrate condition variables into object core framework" 534 default y 535 help 536 When enabled, this option integrates condition variables into the 537 object core framework. 538 539config OBJ_CORE_EVENT 540 bool "Integrate events into object core framework" 541 default y if EVENTS 542 help 543 When enabled, this option integrate kernel events into the object 544 core framework. 545 546config OBJ_CORE_FIFO 547 bool "Integrate FIFOs into object core framework" 548 default y 549 help 550 When enabled, this option integrates FIFOs into the object core 551 framework. 552 553config OBJ_CORE_LIFO 554 bool "Integrate LIFOs into object core framework" 555 default y 556 help 557 When enabled, this option integrates LIFOs into the object core 558 framework. 559 560config OBJ_CORE_MAILBOX 561 bool "Integrate mailboxes into object core framework" 562 default y 563 help 564 When enabled, this option integrates mailboxes into the object core 565 framework. 566 567config OBJ_CORE_MEM_SLAB 568 bool "Integrate memory slabs into object core framework" 569 default y 570 help 571 When enabled, this option integrates memory slabs into the object 572 core framework. 573 574config OBJ_CORE_MUTEX 575 bool "Integrate mutexes into object core framework" 576 default y 577 help 578 When enabled, this option integrates mutexes into the object core 579 framework. 580 581config OBJ_CORE_MSGQ 582 bool "Integrate message queues into object core framework" 583 default y 584 help 585 When enabled, this option integrates message queues into the object 586 core framework. 587 588config OBJ_CORE_SEM 589 bool "Integrate semaphores into object core framework" 590 default y 591 help 592 When enabled, this option integrates semaphores into the object core 593 framework. 594 595config OBJ_CORE_PIPE 596 bool "Integrate pipe into object core framework" 597 default y if PIPES 598 help 599 When enabled, this option integrates pipes into the object core 600 framework. 601 602config OBJ_CORE_SEM 603 bool "Integrate semaphores into object core framework" 604 default y 605 help 606 When enabled, this option integrates semaphores into the object core 607 framework. 608 609config OBJ_CORE_STACK 610 bool "Integrate stacks into object core framework" 611 default y 612 help 613 When enabled, this option integrates stacks into the object core 614 framework. 615 616config OBJ_CORE_THREAD 617 bool "Integrate threads into object core framework" 618 default y 619 help 620 When enabled, this option integrates threads into the object core 621 framework. 622 623config OBJ_CORE_TIMER 624 bool "Integrate timers into object core framework" 625 default y 626 help 627 When enabled, this option integrates timers into the object core 628 framework. 629 630config OBJ_CORE_SYSTEM 631 bool 632 default y 633 help 634 When enabled, this option integrates the internal CPU and kernel 635 system objects into the object core framework. As these are internal 636 structures, this option is hidden by default and only available to 637 advanced users. 638 639menuconfig OBJ_CORE_STATS 640 bool "Object core statistics" 641 default n 642 help 643 This option integrates statistics gathering into the object core 644 framework. 645 646if OBJ_CORE_STATS 647config OBJ_CORE_STATS_MEM_SLAB 648 bool "Object core statistics for memory slabs" 649 default y if OBJ_CORE_MEM_SLAB 650 help 651 When enabled, this allows memory slab statistics to be integrated 652 into kernel objects. 653 654config OBJ_CORE_STATS_THREAD 655 bool "Object core statistics for threads" 656 default y if OBJ_CORE_THREAD 657 select THREAD_RUNTIME_STATS 658 help 659 When enabled, this integrates thread runtime statistics into the 660 object core statistics framework. 661 662config OBJ_CORE_STATS_SYSTEM 663 bool "Object core statistics for system level objects" 664 default y if OBJ_CORE_SYSTEM 665 select SCHED_THREAD_USAGE_ALL 666 help 667 When enabled, this integrates thread runtime statistics at the 668 CPU and system level into the object core statistics framework. 669 670endif # OBJ_CORE_STATS 671 672endif # OBJ_CORE 673 674menu "Work Queue Options" 675config SYSTEM_WORKQUEUE_STACK_SIZE 676 int "System workqueue stack size" 677 default 4096 if COVERAGE_GCOV 678 default 2560 if WIFI_NM_WPA_SUPPLICANT 679 default 1024 680 681config SYSTEM_WORKQUEUE_PRIORITY 682 int "System workqueue priority" 683 default -2 if COOP_ENABLED && !PREEMPT_ENABLED 684 default 0 if !COOP_ENABLED 685 default -1 686 help 687 By default, system work queue priority is the lowest cooperative 688 priority. This means that any work handler, once started, won't 689 be preempted by any other thread until finished. 690 691config SYSTEM_WORKQUEUE_NO_YIELD 692 bool "Select whether system work queue yields" 693 help 694 By default, the system work queue yields between each work item, to 695 prevent other threads from being starved. Selecting this removes 696 this yield, which may be useful if the work queue thread is 697 cooperative and a sequence of work items is expected to complete 698 without yielding. 699 700endmenu 701 702menu "Barrier Operations" 703config BARRIER_OPERATIONS_BUILTIN 704 bool 705 help 706 Use the compiler builtin functions for barrier operations. This is 707 the preferred method. However, support for all arches in GCC is 708 incomplete. 709 710config BARRIER_OPERATIONS_ARCH 711 bool 712 help 713 Use when there isn't support for compiler built-ins, but you have 714 written optimized assembly code under arch/ which implements these. 715endmenu 716 717menu "Atomic Operations" 718config ATOMIC_OPERATIONS_BUILTIN 719 bool 720 help 721 Use the compiler builtin functions for atomic operations. This is 722 the preferred method. However, support for all arches in GCC is 723 incomplete. 724 725config ATOMIC_OPERATIONS_ARCH 726 bool 727 help 728 Use when there isn't support for compiler built-ins, but you have 729 written optimized assembly code under arch/ which implements these. 730 731config ATOMIC_OPERATIONS_C 732 bool 733 help 734 Use atomic operations routines that are implemented entirely 735 in C by locking interrupts. Selected by architectures which either 736 do not have support for atomic operations in their instruction 737 set, or haven't been implemented yet during bring-up, and also 738 the compiler does not have support for the atomic __sync_* builtins. 739endmenu 740 741menu "Timer API Options" 742 743config TIMESLICING 744 bool "Thread time slicing" 745 default y 746 depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0) 747 help 748 This option enables time slicing between preemptible threads of 749 equal priority. 750 751config TIMESLICE_SIZE 752 int "Time slice size (in ms)" 753 default 0 754 range 0 2147483647 755 depends on TIMESLICING 756 help 757 This option specifies the maximum amount of time a thread can execute 758 before other threads of equal priority are given an opportunity to run. 759 A time slice size of zero means "no limit" (i.e. an infinitely large 760 time slice). 761 762config TIMESLICE_PRIORITY 763 int "Time slicing thread priority ceiling" 764 default 0 765 range 0 NUM_PREEMPT_PRIORITIES 766 depends on TIMESLICING 767 help 768 This option specifies the thread priority level at which time slicing 769 takes effect; threads having a higher priority than this ceiling are 770 not subject to time slicing. 771 772config TIMESLICE_PER_THREAD 773 bool "Support per-thread timeslice values" 774 depends on TIMESLICING 775 help 776 When set, this enables an API for setting timeslice values on 777 a per-thread basis, with an application callback invoked when 778 a thread reaches the end of its timeslice. 779 780config POLL 781 bool "Async I/O Framework" 782 help 783 Asynchronous notification framework. Enable the k_poll() and 784 k_poll_signal_raise() APIs. The former can wait on multiple events 785 concurrently, which can be either directly triggered or triggered by 786 the availability of some kernel objects (semaphores and FIFOs). 787 788endmenu 789 790menu "Other Kernel Object Options" 791 792config MEM_SLAB_TRACE_MAX_UTILIZATION 793 bool "Getting maximum slab utilization" 794 help 795 This adds variable to the k_mem_slab structure to hold 796 maximum utilization of the slab. 797 798config NUM_MBOX_ASYNC_MSGS 799 int "Maximum number of in-flight asynchronous mailbox messages" 800 default 10 801 help 802 This option specifies the total number of asynchronous mailbox 803 messages that can exist simultaneously, across all mailboxes 804 in the system. 805 806 Setting this option to 0 disables support for asynchronous 807 mailbox messages. 808 809config EVENTS 810 bool "Event objects" 811 help 812 This option enables event objects. Threads may wait on event 813 objects for specific events, but both threads and ISRs may deliver 814 events to event objects. 815 816 Note that setting this option slightly increases the size of the 817 thread structure. 818 819config PIPES 820 bool "Pipe objects" 821 help 822 This option enables kernel pipes. A pipe is a kernel object that 823 allows a thread to send a byte stream to another thread. Pipes can 824 be used to synchronously transfer chunks of data in whole or in part. 825 826config KERNEL_MEM_POOL 827 bool "Use Kernel Memory Pool" 828 default y 829 help 830 Enable the use of kernel memory pool. 831 832 Say y if unsure. 833 834if KERNEL_MEM_POOL 835 836config HEAP_MEM_POOL_SIZE 837 int "Heap memory pool size (in bytes)" 838 default 0 839 help 840 This option specifies the size of the heap memory pool used when 841 dynamically allocating memory using k_malloc(). The maximum size of 842 the memory pool is only limited to available memory. If subsystems 843 specify HEAP_MEM_POOL_ADD_SIZE_* options, these will be added together 844 and the sum will be compared to the HEAP_MEM_POOL_SIZE value. 845 If the sum is greater than the HEAP_MEM_POOL_SIZE option (even if this 846 has the default 0 value), then the actual heap size will be rounded up 847 to the sum of the individual requirements (unless the 848 HEAP_MEM_POOL_IGNORE_MIN option is enabled). If the final value, after 849 considering both this option as well as sum of the custom 850 requirements, ends up being zero, then no system heap will be 851 available. 852 853config HEAP_MEM_POOL_IGNORE_MIN 854 bool "Ignore the minimum heap memory pool requirement" 855 help 856 This option can be set to force setting a smaller heap memory pool 857 size than what's specified by enabled subsystems. This can be useful 858 when optimizing memory usage and a more precise minimum heap size 859 is known for a given application. 860 861endif # KERNEL_MEM_POOL 862 863endmenu 864 865config ARCH_HAS_CUSTOM_SWAP_TO_MAIN 866 bool 867 help 868 It's possible that an architecture port cannot use _Swap() to swap to 869 the _main() thread, but instead must do something custom. It must 870 enable this option in that case. 871 872config SWAP_NONATOMIC 873 bool 874 help 875 On some architectures, the _Swap() primitive cannot be made 876 atomic with respect to the irq_lock being released. That 877 is, interrupts may be received between the entry to _Swap 878 and the completion of the context switch. There are a 879 handful of workaround cases in the kernel that need to be 880 enabled when this is true. Currently, this only happens on 881 ARM when the PendSV exception priority sits below that of 882 Zephyr-handled interrupts. 883 884config ARCH_HAS_CUSTOM_BUSY_WAIT 885 bool 886 help 887 It's possible that an architecture port cannot or does not want to use 888 the provided k_busy_wait(), but instead must do something custom. It must 889 enable this option in that case. 890 891config SYS_CLOCK_TICKS_PER_SEC 892 int "System tick frequency (in ticks/second)" 893 default 100 if QEMU_TARGET || SOC_POSIX 894 default 10000 if TICKLESS_KERNEL 895 default 100 896 help 897 This option specifies the nominal frequency of the system clock in Hz. 898 899 For asynchronous timekeeping, the kernel defines a "ticks" concept. A 900 "tick" is the internal count in which the kernel does all its internal 901 uptime and timeout bookkeeping. Interrupts are expected to be delivered 902 on tick boundaries to the extent practical, and no fractional ticks 903 are tracked. 904 905 The choice of tick rate is configurable by this option. Also the number 906 of cycles per tick should be chosen so that 1 millisecond is exactly 907 represented by an integral number of ticks. Defaults on most hardware 908 platforms (ones that support setting arbitrary interrupt timeouts) are 909 expected to be in the range of 10 kHz, with software emulation 910 platforms and legacy drivers using a more traditional 100 Hz value. 911 912 Note that when available and enabled, in "tickless" mode 913 this config variable specifies the minimum available timing 914 granularity, not necessarily the number or frequency of 915 interrupts delivered to the kernel. 916 917 A value of 0 completely disables timer support in the kernel. 918 919config SYS_CLOCK_HW_CYCLES_PER_SEC 920 int "System clock's h/w timer frequency" 921 help 922 This option specifies the frequency of the hardware timer used for the 923 system clock (in Hz). This option is set by the SOC's or board's Kconfig file 924 and the user should generally avoid modifying it via the menu configuration. 925 926config SYS_CLOCK_EXISTS 927 bool "System clock exists and is enabled" 928 default y 929 help 930 This option specifies that the kernel has timer support. 931 932 Some device configurations can eliminate significant code if 933 this is disabled. Obviously timeout-related APIs will not 934 work when disabled. 935 936config TIMEOUT_64BIT 937 bool "Store kernel timeouts in 64 bit precision" 938 default y 939 help 940 When this option is true, the k_ticks_t values passed to 941 kernel APIs will be a 64 bit quantity, allowing the use of 942 larger values (and higher precision tick rates) without fear 943 of overflowing the 32 bit word. This feature also gates the 944 availability of absolute timeout values (which require the 945 extra precision). 946 947config SYS_CLOCK_MAX_TIMEOUT_DAYS 948 int "Max timeout (in days) used in conversions" 949 default 365 950 help 951 Value is used in the time conversion static inline function to determine 952 at compile time which algorithm to use. One algorithm is faster, takes 953 less code but may overflow if multiplication of source and target 954 frequency exceeds 64 bits. Second algorithm prevents that. Faster 955 algorithm is selected for conversion if maximum timeout represented in 956 source frequency domain multiplied by target frequency fits in 64 bits. 957 958config BUSYWAIT_CPU_LOOPS_PER_USEC 959 int "Number of CPU loops per microsecond for crude busy looping" 960 depends on !SYS_CLOCK_EXISTS && !ARCH_HAS_CUSTOM_BUSY_WAIT 961 default 500 962 help 963 Calibration for crude CPU based busy loop duration. The default 964 is assuming 1 GHz CPU and 2 cycles per loop. Reality is certainly 965 much worse but all we want here is a ball-park figure that ought 966 to be good enough for the purpose of being able to configure out 967 system timer support. If accuracy is very important then 968 implementing arch_busy_wait() should be considered. 969 970config XIP 971 bool "Execute in place" 972 help 973 This option allows the kernel to operate with its text and read-only 974 sections residing in ROM (or similar read-only memory). Not all boards 975 support this option so it must be used with care; you must also 976 supply a linker command file when building your image. Enabling this 977 option increases both the code and data footprint of the image. 978 979menu "Initialization Priorities" 980 981config KERNEL_INIT_PRIORITY_OBJECTS 982 int "Kernel objects initialization priority" 983 default 30 984 help 985 Kernel objects use this priority for initialization. This 986 priority needs to be higher than minimal default initialization 987 priority. 988 989config KERNEL_INIT_PRIORITY_DEFAULT 990 int "Default init priority" 991 default 40 992 help 993 Default minimal init priority for each init level. 994 995config KERNEL_INIT_PRIORITY_DEVICE 996 int "Default init priority for device drivers" 997 default 50 998 help 999 Device driver, that depends on common components, such as 1000 interrupt controller, but does not depend on other devices, 1001 uses this init priority. 1002 1003config APPLICATION_INIT_PRIORITY 1004 int "Default init priority for application level drivers" 1005 default 90 1006 help 1007 This priority level is for end-user drivers such as sensors and display 1008 which have no inward dependencies. 1009 1010 1011endmenu 1012 1013menu "Security Options" 1014 1015config STACK_CANARIES 1016 bool "Compiler stack canaries" 1017 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 1018 select NEED_LIBC_MEM_PARTITION if !STACK_CANARIES_TLS 1019 help 1020 This option enables compiler stack canaries. 1021 1022 If stack canaries are supported by the compiler, it will emit 1023 extra code that inserts a canary value into the stack frame when 1024 a function is entered and validates this value upon exit. 1025 Stack corruption (such as that caused by buffer overflow) results 1026 in a fatal error condition for the running entity. 1027 Enabling this option can result in a significant increase 1028 in footprint and an associated decrease in performance. 1029 1030 If stack canaries are not supported by the compiler an error 1031 will occur at build time. 1032 1033if STACK_CANARIES 1034 1035config STACK_CANARIES_TLS 1036 bool "Stack canaries using thread local storage" 1037 depends on THREAD_LOCAL_STORAGE 1038 depends on ARCH_HAS_STACK_CANARIES_TLS 1039 help 1040 This option enables compiler stack canaries on TLS. 1041 1042 Stack canaries will leave in the thread local storage and 1043 each thread will have its own canary. This makes harder 1044 to predict the canary location and value. 1045 1046 When enabled this causes an additional performance penalty 1047 during thread creations because it needs a new random value 1048 per thread. 1049endif 1050 1051config EXECUTE_XOR_WRITE 1052 bool "W^X for memory partitions" 1053 depends on USERSPACE 1054 depends on ARCH_HAS_EXECUTABLE_PAGE_BIT 1055 default y 1056 help 1057 When enabled, will enforce that a writable page isn't executable 1058 and vice versa. This might not be acceptable in all scenarios, 1059 so this option is given for those unafraid of shooting themselves 1060 in the foot. 1061 1062 If unsure, say Y. 1063 1064config STACK_POINTER_RANDOM 1065 int "Initial stack pointer randomization bounds" 1066 depends on !STACK_GROWS_UP 1067 depends on MULTITHREADING 1068 depends on TEST_RANDOM_GENERATOR || ENTROPY_HAS_DRIVER 1069 default 0 1070 help 1071 This option performs a limited form of Address Space Layout 1072 Randomization by offsetting some random value to a thread's 1073 initial stack pointer upon creation. This hinders some types of 1074 security attacks by making the location of any given stack frame 1075 non-deterministic. 1076 1077 This feature can waste up to the specified size in bytes the stack 1078 region, which is carved out of the total size of the stack region. 1079 A reasonable minimum value would be around 100 bytes if this can 1080 be spared. 1081 1082 This is currently only implemented for systems whose stack pointers 1083 grow towards lower memory addresses. 1084 1085config BOUNDS_CHECK_BYPASS_MITIGATION 1086 bool "Bounds check bypass mitigations for speculative execution" 1087 depends on USERSPACE 1088 help 1089 Untrusted parameters from user mode may be used in system calls to 1090 index arrays during speculative execution, also known as the Spectre 1091 V1 vulnerability. When enabled, various macros defined in 1092 misc/speculation.h will insert fence instructions or other appropriate 1093 mitigations after bounds checking any array index parameters passed 1094 in from untrusted sources (user mode threads). When disabled, these 1095 macros do nothing. 1096endmenu 1097 1098config MAX_DOMAIN_PARTITIONS 1099 int "Maximum number of partitions per memory domain" 1100 default 16 1101 range 0 255 1102 depends on USERSPACE 1103 help 1104 Configure the maximum number of partitions per memory domain. 1105 1106config ARCH_MEM_DOMAIN_DATA 1107 bool 1108 depends on USERSPACE 1109 help 1110 This hidden option is selected by the target architecture if 1111 architecture-specific data is needed on a per memory domain basis. 1112 If so, the architecture defines a 'struct arch_mem_domain' which is 1113 embedded within every struct k_mem_domain. The architecture 1114 must also define the arch_mem_domain_init() function to set this up 1115 when a memory domain is created. 1116 1117 Typical uses might be a set of page tables for that memory domain. 1118 1119config ARCH_MEM_DOMAIN_SYNCHRONOUS_API 1120 bool 1121 depends on USERSPACE 1122 help 1123 This hidden option is selected by the target architecture if 1124 modifying a memory domain's partitions at runtime, or changing 1125 a memory domain's thread membership requires synchronous calls 1126 into the architecture layer. 1127 1128 If enabled, the architecture layer must implement the following 1129 APIs: 1130 1131 arch_mem_domain_thread_add 1132 arch_mem_domain_thread_remove 1133 arch_mem_domain_partition_remove 1134 arch_mem_domain_partition_add 1135 1136 It's important to note that although supervisor threads can be 1137 members of memory domains, they have no implications on supervisor 1138 thread access to memory. Memory domain APIs may only be invoked from 1139 supervisor mode. 1140 1141 For these reasons, on uniprocessor systems unless memory access 1142 policy is managed in separate software constructions like page 1143 tables, these APIs don't need to be implemented as the underlying 1144 memory management hardware will be reprogrammed on context switch 1145 anyway. 1146 1147menu "SMP Options" 1148 1149config SMP 1150 bool "Symmetric multiprocessing support" 1151 depends on USE_SWITCH 1152 depends on !ATOMIC_OPERATIONS_C 1153 help 1154 When true, kernel will be built with SMP support, allowing 1155 more than one CPU to schedule Zephyr tasks at a time. 1156 1157config USE_SWITCH 1158 bool "Use new-style _arch_switch instead of arch_swap" 1159 depends on USE_SWITCH_SUPPORTED 1160 help 1161 The _arch_switch() API is a lower level context switching 1162 primitive than the original arch_swap mechanism. It is required 1163 for an SMP-aware scheduler, or if the architecture does not 1164 provide arch_swap. In uniprocess situations where the 1165 architecture provides both, _arch_switch incurs more somewhat 1166 overhead and may be slower. 1167 1168config USE_SWITCH_SUPPORTED 1169 bool 1170 help 1171 Indicates whether _arch_switch() API is supported by the 1172 currently enabled platform. This option should be selected by 1173 platforms that implement it. 1174 1175config SMP_BOOT_DELAY 1176 bool "Delay booting secondary cores" 1177 depends on SMP 1178 help 1179 By default Zephyr will boot all available CPUs during start up. 1180 Select this option to skip this and allow custom code 1181 (architecture/SoC/board/application) to boot secondary CPUs at 1182 a later time. 1183 1184config MP_NUM_CPUS 1185 int "Number of CPUs/cores [DEPRECATED]" 1186 default MP_MAX_NUM_CPUS 1187 range 1 12 1188 help 1189 This is deprecated, please use MP_MAX_NUM_CPUS instead. 1190 1191config MP_MAX_NUM_CPUS 1192 int "Maximum number of CPUs/cores" 1193 default 1 1194 range 1 12 1195 help 1196 Maximum number of multiprocessing-capable cores available to the 1197 multicpu API and SMP features. 1198 1199config SCHED_IPI_SUPPORTED 1200 bool 1201 help 1202 True if the architecture supports a call to 1203 arch_sched_ipi() to broadcast an interrupt that will call 1204 z_sched_ipi() on other CPUs in the system. Required for 1205 k_thread_abort() to operate with reasonable latency 1206 (otherwise we might have to wait for the other thread to 1207 take an interrupt, which can be arbitrarily far in the 1208 future). 1209 1210config TRACE_SCHED_IPI 1211 bool "Test IPI" 1212 help 1213 When true, it will add a hook into z_sched_ipi(), in order 1214 to check if schedule IPI has called or not, for testing 1215 purpose. 1216 depends on SCHED_IPI_SUPPORTED 1217 depends on MP_MAX_NUM_CPUS>1 1218 1219config KERNEL_COHERENCE 1220 bool "Place all shared data into coherent memory" 1221 depends on ARCH_HAS_COHERENCE 1222 default y if SMP && MP_MAX_NUM_CPUS > 1 1223 select THREAD_STACK_INFO 1224 help 1225 When available and selected, the kernel will build in a mode 1226 where all shared data is placed in multiprocessor-coherent 1227 (generally "uncached") memory. Thread stacks will remain 1228 cached, as will application memory declared with 1229 __incoherent. This is intended for Zephyr SMP kernels 1230 running on cache-incoherent architectures only. Note that 1231 when this is selected, there is an implicit API change that 1232 assumes cache coherence to any memory passed to the kernel. 1233 Code that creates kernel data structures in uncached regions 1234 may fail strangely. Some assertions exist to catch these 1235 mistakes, but not all circumstances can be tested. 1236 1237config TICKET_SPINLOCKS 1238 bool "Ticket spinlocks for lock acquisition fairness [EXPERIMENTAL]" 1239 select EXPERIMENTAL 1240 help 1241 Basic spinlock implementation is based on single 1242 atomic variable and doesn't guarantee locking fairness 1243 across multiple CPUs. It's even possible that single CPU 1244 will win the contention every time which will result 1245 in a live-lock. 1246 Ticket spinlocks provide a FIFO order of lock acquisition 1247 which resolves such unfairness issue at the cost of slightly 1248 increased memory footprint. 1249 1250endmenu 1251 1252config TICKLESS_KERNEL 1253 bool "Tickless kernel" 1254 default y if TICKLESS_CAPABLE 1255 depends on TICKLESS_CAPABLE 1256 help 1257 This option enables a fully event driven kernel. Periodic system 1258 clock interrupt generation would be stopped at all times. 1259 1260config TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 1261 bool 1262 default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" || "$(ZEPHYR_TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE)" = "y" 1263 help 1264 Hidden option to signal that toolchain supports generating code 1265 with thread local storage. 1266 1267config THREAD_LOCAL_STORAGE 1268 bool "Thread Local Storage (TLS)" 1269 depends on ARCH_HAS_THREAD_LOCAL_STORAGE && TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 1270 select NEED_LIBC_MEM_PARTITION if (CPU_CORTEX_M && USERSPACE) 1271 help 1272 This option enables thread local storage (TLS) support in kernel. 1273 1274endmenu 1275 1276menu "Device Options" 1277 1278config DEVICE_DEPS 1279 bool "Store device dependencies" 1280 help 1281 When enabled, device dependencies will be stored so that they can be 1282 queried at runtime. Device dependencies are typically inferred from 1283 devicetree. Enabling this option will increase ROM usage (or RAM if 1284 dynamic device dependencies are enabled). 1285 1286config DEVICE_DEPS_DYNAMIC 1287 bool "Dynamic device dependencies" 1288 depends on DEVICE_DEPS 1289 help 1290 Option that makes it possible to manipulate device dependencies at 1291 runtime. 1292 1293config DEVICE_MUTABLE 1294 bool "Mutable devices [EXPERIMENTAL]" 1295 select EXPERIMENTAL 1296 help 1297 Support mutable devices. Mutable devices are instantiated in SRAM 1298 instead of Flash and are runtime modifiable in kernel mode. 1299 1300endmenu 1301 1302rsource "Kconfig.vm" 1303
