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