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 "Enable 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 "Enable 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 MAIN_STACK_SIZE 140 int "Size of stack for initialization and main thread" 141 default 2048 if COVERAGE_GCOV 142 default 1024 if TEST_ARM_CORTEX_M 143 default 512 if ZTEST && !(RISCV || X86) 144 default 1024 145 help 146 When the initialization is complete, the thread executing it then 147 executes the main() routine, so as to reuse the stack used by the 148 initialization, which would be wasted RAM otherwise. 149 150 After initialization is complete, the thread runs main(). 151 152config IDLE_STACK_SIZE 153 int "Size of stack for idle thread" 154 default 2048 if COVERAGE_GCOV 155 default 1024 if XTENSA 156 default 512 if RISCV 157 default 384 if DYNAMIC_OBJECTS 158 default 320 if ARC || (ARM && CPU_HAS_FPU) || (X86 && MMU) 159 default 256 160 help 161 Depending on the work that the idle task must do, most likely due to 162 power management but possibly to other features like system event 163 logging (e.g. logging when the system goes to sleep), the idle thread 164 may need more stack space than the default value. 165 166config ISR_STACK_SIZE 167 int "ISR and initialization stack size (in bytes)" 168 default 2048 169 help 170 This option specifies the size of the stack used by interrupt 171 service routines (ISRs), and during kernel initialization. 172 173config THREAD_STACK_INFO 174 bool "Thread stack info" 175 help 176 This option allows each thread to store the thread stack info into 177 the k_thread data structure. 178 179config THREAD_CUSTOM_DATA 180 bool "Thread custom data" 181 help 182 This option allows each thread to store 32 bits of custom data, 183 which can be accessed using the k_thread_custom_data_xxx() APIs. 184 185config THREAD_USERSPACE_LOCAL_DATA 186 bool 187 depends on USERSPACE 188 default y if ERRNO && !ERRNO_IN_TLS 189 190config ERRNO 191 bool "Enable errno support" 192 default y 193 help 194 Enable per-thread errno in the kernel. Application and library code must 195 include errno.h provided by the C library (libc) to use the errno 196 symbol. The C library must access the per-thread errno via the 197 z_errno() symbol. 198 199config ERRNO_IN_TLS 200 bool "Store errno in thread local storage (TLS)" 201 depends on ERRNO && THREAD_LOCAL_STORAGE 202 default y 203 help 204 Use thread local storage to store errno instead of storing it in 205 the kernel thread struct. This avoids a syscall if userspace is enabled. 206 207choice SCHED_ALGORITHM 208 prompt "Scheduler priority queue algorithm" 209 default SCHED_DUMB 210 help 211 The kernel can be built with with several choices for the 212 ready queue implementation, offering different choices between 213 code size, constant factor runtime overhead and performance 214 scaling when many threads are added. 215 216config SCHED_DUMB 217 bool "Simple linked-list ready queue" 218 help 219 When selected, the scheduler ready queue will be implemented 220 as a simple unordered list, with very fast constant time 221 performance for single threads and very low code size. 222 Choose this on systems with constrained code size that will 223 never see more than a small number (3, maybe) of runnable 224 threads in the queue at any given time. On most platforms 225 (that are not otherwise using the red/black tree) this 226 results in a savings of ~2k of code size. 227 228config SCHED_SCALABLE 229 bool "Red/black tree ready queue" 230 help 231 When selected, the scheduler ready queue will be implemented 232 as a red/black tree. This has rather slower constant-time 233 insertion and removal overhead, and on most platforms (that 234 are not otherwise using the rbtree somewhere) requires an 235 extra ~2kb of code. But the resulting behavior will scale 236 cleanly and quickly into the many thousands of threads. Use 237 this on platforms where you may have many threads (very 238 roughly: more than 20 or so) marked as runnable at a given 239 time. Most applications don't want this. 240 241config SCHED_MULTIQ 242 bool "Traditional multi-queue ready queue" 243 depends on !SCHED_DEADLINE 244 help 245 When selected, the scheduler ready queue will be implemented 246 as the classic/textbook array of lists, one per priority 247 (max 32 priorities). This corresponds to the scheduler 248 algorithm used in Zephyr versions prior to 1.12. It incurs 249 only a tiny code size overhead vs. the "dumb" scheduler and 250 runs in O(1) time in almost all circumstances with very low 251 constant factor. But it requires a fairly large RAM budget 252 to store those list heads, and the limited features make it 253 incompatible with features like deadline scheduling that 254 need to sort threads more finely, and SMP affinity which 255 need to traverse the list of threads. Typical applications 256 with small numbers of runnable threads probably want the 257 DUMB scheduler. 258 259endchoice # SCHED_ALGORITHM 260 261choice WAITQ_ALGORITHM 262 prompt "Wait queue priority algorithm" 263 default WAITQ_DUMB 264 help 265 The wait_q abstraction used in IPC primitives to pend 266 threads for later wakeup shares the same backend data 267 structure choices as the scheduler, and can use the same 268 options. 269 270config WAITQ_SCALABLE 271 bool "Use scalable wait_q implementation" 272 help 273 When selected, the wait_q will be implemented with a 274 balanced tree. Choose this if you expect to have many 275 threads waiting on individual primitives. There is a ~2kb 276 code size increase over WAITQ_DUMB (which may be shared with 277 SCHED_SCALABLE) if the rbtree is not used elsewhere in the 278 application, and pend/unpend operations on "small" queues 279 will be somewhat slower (though this is not generally a 280 performance path). 281 282config WAITQ_DUMB 283 bool "Simple linked-list wait_q" 284 help 285 When selected, the wait_q will be implemented with a 286 doubly-linked list. Choose this if you expect to have only 287 a few threads blocked on any single IPC primitive. 288 289endchoice # WAITQ_ALGORITHM 290 291config DEVICE_HANDLE_PADDING 292 int "Number of additional device handles to use for padding" 293 default 0 294 range 0 10 295 help 296 This is a "fudge factor" which works around build system 297 limitations. It is safe to ignore unless you get a specific 298 build system error about it. 299 300 The option's value is the number of superfluous device handle 301 values which are introduced into the array pointed to by each 302 device's 'handles' member during the first linker pass. 303 304 Each handle uses 2 bytes, so a value of 3 would use an extra 305 6 bytes of ROM for every device. 306 307menu "Kernel Debugging and Metrics" 308 309config INIT_STACKS 310 bool "Initialize stack areas" 311 help 312 This option instructs the kernel to initialize stack areas with a 313 known value (0xaa) before they are first used, so that the high 314 water mark can be easily determined. This applies to the stack areas 315 for threads, as well as to the interrupt stack. 316 317config BOOT_BANNER 318 bool "Boot banner" 319 default y 320 depends on CONSOLE_HAS_DRIVER 321 select PRINTK 322 select EARLY_CONSOLE 323 help 324 This option outputs a banner to the console device during boot up. 325 326config BOOT_DELAY 327 int "Boot delay in milliseconds" 328 default 0 329 help 330 This option delays bootup for the specified amount of 331 milliseconds. This is used to allow serial ports to get ready 332 before starting to print information on them during boot, as 333 some systems might boot to fast for a receiving endpoint to 334 detect the new USB serial bus, enumerate it and get ready to 335 receive before it actually gets data. A similar effect can be 336 achieved by waiting for DCD on the serial port--however, not 337 all serial ports have DCD. 338 339config THREAD_MONITOR 340 bool "Thread monitoring" 341 help 342 This option instructs the kernel to maintain a list of all threads 343 (excluding those that have not yet started or have already 344 terminated). 345 346config THREAD_NAME 347 bool "Thread name" 348 help 349 This option allows to set a name for a thread. 350 351config THREAD_MAX_NAME_LEN 352 int "Max length of a thread name" 353 default 32 354 default 64 if ZTEST 355 range 8 128 356 depends on THREAD_NAME 357 help 358 Thread names get stored in the k_thread struct. Indicate the max 359 name length, including the terminating NULL byte. Reduce this value 360 to conserve memory. 361 362config INSTRUMENT_THREAD_SWITCHING 363 bool 364 365menuconfig THREAD_RUNTIME_STATS 366 bool "Thread runtime statistics" 367 select INSTRUMENT_THREAD_SWITCHING 368 help 369 Gather thread runtime statistics. 370 371 For example: 372 - Thread total execution cycles 373 374if THREAD_RUNTIME_STATS 375 376config THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS 377 bool "Use timing functions to gather statistics" 378 select TIMING_FUNCTIONS_NEED_AT_BOOT 379 help 380 Use timing functions to gather thread runtime statistics. 381 382 Note that timing functions may use a different timer than 383 the default timer for OS timekeeping. 384 385endif # THREAD_RUNTIME_STATS 386 387endmenu 388 389menu "Work Queue Options" 390config SYSTEM_WORKQUEUE_STACK_SIZE 391 int "System workqueue stack size" 392 default 4096 if COVERAGE 393 default 1024 394 395config SYSTEM_WORKQUEUE_PRIORITY 396 int "System workqueue priority" 397 default -2 if COOP_ENABLED && !PREEMPT_ENABLED 398 default 0 if !COOP_ENABLED 399 default -1 400 help 401 By default, system work queue priority is the lowest cooperative 402 priority. This means that any work handler, once started, won't 403 be preempted by any other thread until finished. 404 405config SYSTEM_WORKQUEUE_NO_YIELD 406 bool "Select whether system work queue yields" 407 help 408 By default, the system work queue yields between each work item, to 409 prevent other threads from being starved. Selecting this removes 410 this yield, which may be useful if the work queue thread is 411 cooperative and a sequence of work items is expected to complete 412 without yielding. 413 414endmenu 415 416menu "Atomic Operations" 417config ATOMIC_OPERATIONS_BUILTIN 418 bool 419 help 420 Use the compiler builtin functions for atomic operations. This is 421 the preferred method. However, support for all arches in GCC is 422 incomplete. 423 424config ATOMIC_OPERATIONS_ARCH 425 bool 426 help 427 Use when there isn't support for compiler built-ins, but you have 428 written optimized assembly code under arch/ which implements these. 429 430config ATOMIC_OPERATIONS_C 431 bool 432 help 433 Use atomic operations routines that are implemented entirely 434 in C by locking interrupts. Selected by architectures which either 435 do not have support for atomic operations in their instruction 436 set, or haven't been implemented yet during bring-up, and also 437 the compiler does not have support for the atomic __sync_* builtins. 438endmenu 439 440menu "Timer API Options" 441 442config TIMESLICING 443 bool "Thread time slicing" 444 default y 445 depends on SYS_CLOCK_EXISTS && (NUM_PREEMPT_PRIORITIES != 0) 446 help 447 This option enables time slicing between preemptible threads of 448 equal priority. 449 450config TIMESLICE_SIZE 451 int "Time slice size (in ms)" 452 default 0 453 range 0 2147483647 454 depends on TIMESLICING 455 help 456 This option specifies the maximum amount of time a thread can execute 457 before other threads of equal priority are given an opportunity to run. 458 A time slice size of zero means "no limit" (i.e. an infinitely large 459 time slice). 460 461config TIMESLICE_PRIORITY 462 int "Time slicing thread priority ceiling" 463 default 0 464 range 0 NUM_PREEMPT_PRIORITIES 465 depends on TIMESLICING 466 help 467 This option specifies the thread priority level at which time slicing 468 takes effect; threads having a higher priority than this ceiling are 469 not subject to time slicing. 470 471config POLL 472 bool "Async I/O Framework" 473 help 474 Asynchronous notification framework. Enable the k_poll() and 475 k_poll_signal_raise() APIs. The former can wait on multiple events 476 concurrently, which can be either directly triggered or triggered by 477 the availability of some kernel objects (semaphores and FIFOs). 478 479endmenu 480 481menu "Other Kernel Object Options" 482 483config MEM_SLAB_TRACE_MAX_UTILIZATION 484 bool "Enable getting maximum slab utilization" 485 help 486 This adds variable to the k_mem_slab structure to hold 487 maximum utilization of the slab. 488 489config NUM_MBOX_ASYNC_MSGS 490 int "Maximum number of in-flight asynchronous mailbox messages" 491 default 10 492 help 493 This option specifies the total number of asynchronous mailbox 494 messages that can exist simultaneously, across all mailboxes 495 in the system. 496 497 Setting this option to 0 disables support for asynchronous 498 mailbox messages. 499 500config NUM_PIPE_ASYNC_MSGS 501 int "Maximum number of in-flight asynchronous pipe messages" 502 default 10 503 help 504 This option specifies the total number of asynchronous pipe 505 messages that can exist simultaneously, across all pipes in 506 the system. 507 508 Setting this option to 0 disables support for asynchronous 509 pipe messages. 510 511config KERNEL_MEM_POOL 512 bool "Use Kernel Memory Pool" 513 default y 514 help 515 Enable the use of kernel memory pool. 516 517 Say y if unsure. 518 519if KERNEL_MEM_POOL 520 521config HEAP_MEM_POOL_SIZE 522 int "Heap memory pool size (in bytes)" 523 default 0 if !POSIX_MQUEUE 524 default 1024 if POSIX_MQUEUE 525 help 526 This option specifies the size of the heap memory pool used when 527 dynamically allocating memory using k_malloc(). The maximum size of 528 the memory pool is only limited to available memory. A size of zero 529 means that no heap memory pool is defined. 530 531endif # KERNEL_MEM_POOL 532 533endmenu 534 535config ARCH_HAS_CUSTOM_SWAP_TO_MAIN 536 bool 537 help 538 It's possible that an architecture port cannot use _Swap() to swap to 539 the _main() thread, but instead must do something custom. It must 540 enable this option in that case. 541 542config SWAP_NONATOMIC 543 bool 544 help 545 On some architectures, the _Swap() primitive cannot be made 546 atomic with respect to the irq_lock being released. That 547 is, interrupts may be received between the entry to _Swap 548 and the completion of the context switch. There are a 549 handful of workaround cases in the kernel that need to be 550 enabled when this is true. Currently, this only happens on 551 ARM when the PendSV exception priority sits below that of 552 Zephyr-handled interrupts. 553 554config ARCH_HAS_CUSTOM_BUSY_WAIT 555 bool 556 help 557 It's possible that an architecture port cannot or does not want to use 558 the provided k_busy_wait(), but instead must do something custom. It must 559 enable this option in that case. 560 561config SYS_CLOCK_TICKS_PER_SEC 562 int "System tick frequency (in ticks/second)" 563 default 100 if QEMU_TARGET || SOC_POSIX 564 default 10000 if TICKLESS_KERNEL 565 default 100 566 help 567 This option specifies the nominal frequency of the system clock in Hz. 568 569 For asynchronous timekeeping, the kernel defines a "ticks" concept. A 570 "tick" is the internal count in which the kernel does all its internal 571 uptime and timeout bookkeeping. Interrupts are expected to be delivered 572 on tick boundaries to the extent practical, and no fractional ticks 573 are tracked. 574 575 The choice of tick rate is configurable by this option. Also the number 576 of cycles per tick should be chosen so that 1 millisecond is exactly 577 represented by an integral number of ticks. Defaults on most hardware 578 platforms (ones that support setting arbitrary interrupt timeouts) are 579 expected to be in the range of 10 kHz, with software emulation 580 platforms and legacy drivers using a more traditional 100 Hz value. 581 582 Note that when available and enabled, in "tickless" mode 583 this config variable specifies the minimum available timing 584 granularity, not necessarily the number or frequency of 585 interrupts delivered to the kernel. 586 587 A value of 0 completely disables timer support in the kernel. 588 589config SYS_CLOCK_HW_CYCLES_PER_SEC 590 int "System clock's h/w timer frequency" 591 help 592 This option specifies the frequency of the hardware timer used for the 593 system clock (in Hz). This option is set by the SOC's or board's Kconfig file 594 and the user should generally avoid modifying it via the menu configuration. 595 596config SYS_CLOCK_EXISTS 597 bool "System clock exists and is enabled" 598 default y 599 help 600 This option specifies that the kernel lacks timer support. 601 Some device configurations can eliminate significant code if 602 this is disabled. Obviously timeout-related APIs will not 603 work. 604 605config TIMEOUT_64BIT 606 bool "Store kernel timeouts in 64 bit precision" 607 default y 608 help 609 When this option is true, the k_ticks_t values passed to 610 kernel APIs will be a 64 bit quantity, allowing the use of 611 larger values (and higher precision tick rates) without fear 612 of overflowing the 32 bit word. This feature also gates the 613 availability of absolute timeout values (which require the 614 extra precision). 615 616config SYS_CLOCK_MAX_TIMEOUT_DAYS 617 int "Max timeout (in days) used in conversions" 618 default 365 619 help 620 Value is used in the time conversion static inline function to determine 621 at compile time which algorithm to use. One algorithm is faster, takes 622 less code but may overflow if multiplication of source and target 623 frequency exceeds 64 bits. Second algorithm prevents that. Faster 624 algorithm is selected for conversion if maximum timeout represented in 625 source frequency domain multiplied by target frequency fits in 64 bits. 626 627config XIP 628 bool "Execute in place" 629 help 630 This option allows the kernel to operate with its text and read-only 631 sections residing in ROM (or similar read-only memory). Not all boards 632 support this option so it must be used with care; you must also 633 supply a linker command file when building your image. Enabling this 634 option increases both the code and data footprint of the image. 635 636menu "Initialization Priorities" 637 638config KERNEL_INIT_PRIORITY_OBJECTS 639 int "Kernel objects initialization priority" 640 default 30 641 help 642 Kernel objects use this priority for initialization. This 643 priority needs to be higher than minimal default initialization 644 priority. 645 646config KERNEL_INIT_PRIORITY_DEFAULT 647 int "Default init priority" 648 default 40 649 help 650 Default minimal init priority for each init level. 651 652config KERNEL_INIT_PRIORITY_DEVICE 653 int "Default init priority for device drivers" 654 default 50 655 help 656 Device driver, that depends on common components, such as 657 interrupt controller, but does not depend on other devices, 658 uses this init priority. 659 660config APPLICATION_INIT_PRIORITY 661 int "Default init priority for application level drivers" 662 default 90 663 help 664 This priority level is for end-user drivers such as sensors and display 665 which have no inward dependencies. 666 667 668endmenu 669 670menu "Security Options" 671 672config STACK_CANARIES 673 bool "Compiler stack canaries" 674 depends on ENTROPY_GENERATOR || TEST_RANDOM_GENERATOR 675 help 676 This option enables compiler stack canaries. 677 678 If stack canaries are supported by the compiler, it will emit 679 extra code that inserts a canary value into the stack frame when 680 a function is entered and validates this value upon exit. 681 Stack corruption (such as that caused by buffer overflow) results 682 in a fatal error condition for the running entity. 683 Enabling this option can result in a significant increase 684 in footprint and an associated decrease in performance. 685 686 If stack canaries are not supported by the compiler an error 687 will occur at build time. 688 689config EXECUTE_XOR_WRITE 690 bool "Enable W^X for memory partitions" 691 depends on USERSPACE 692 depends on ARCH_HAS_EXECUTABLE_PAGE_BIT 693 default y 694 help 695 When enabled, will enforce that a writable page isn't executable 696 and vice versa. This might not be acceptable in all scenarios, 697 so this option is given for those unafraid of shooting themselves 698 in the foot. 699 700 If unsure, say Y. 701 702config STACK_POINTER_RANDOM 703 int "Initial stack pointer randomization bounds" 704 depends on !STACK_GROWS_UP 705 depends on MULTITHREADING 706 depends on TEST_RANDOM_GENERATOR || ENTROPY_HAS_DRIVER 707 default 0 708 help 709 This option performs a limited form of Address Space Layout 710 Randomization by offsetting some random value to a thread's 711 initial stack pointer upon creation. This hinders some types of 712 security attacks by making the location of any given stack frame 713 non-deterministic. 714 715 This feature can waste up to the specified size in bytes the stack 716 region, which is carved out of the total size of the stack region. 717 A reasonable minimum value would be around 100 bytes if this can 718 be spared. 719 720 This is currently only implemented for systems whose stack pointers 721 grow towards lower memory addresses. 722 723config BOUNDS_CHECK_BYPASS_MITIGATION 724 bool "Enable bounds check bypass mitigations for speculative execution" 725 depends on USERSPACE 726 help 727 Untrusted parameters from user mode may be used in system calls to 728 index arrays during speculative execution, also known as the Spectre 729 V1 vulnerability. When enabled, various macros defined in 730 misc/speculation.h will insert fence instructions or other appropriate 731 mitigations after bounds checking any array index parameters passed 732 in from untrusted sources (user mode threads). When disabled, these 733 macros do nothing. 734endmenu 735 736config MAX_DOMAIN_PARTITIONS 737 int "Maximum number of partitions per memory domain" 738 default 16 739 range 0 255 740 depends on USERSPACE 741 help 742 Configure the maximum number of partitions per memory domain. 743 744config ARCH_MEM_DOMAIN_DATA 745 bool 746 depends on USERSPACE 747 help 748 This hidden option is selected by the target architecture if 749 architecture-specific data is needed on a per memory domain basis. 750 If so, the architecture defines a 'struct arch_mem_domain' which is 751 embedded within every struct k_mem_domain. The architecture 752 must also define the arch_mem_domain_init() function to set this up 753 when a memory domain is created. 754 755 Typical uses might be a set of page tables for that memory domain. 756 757config ARCH_MEM_DOMAIN_SYNCHRONOUS_API 758 bool 759 depends on USERSPACE 760 help 761 This hidden option is selected by the target architecture if 762 modifying a memory domain's partitions at runtime, or changing 763 a memory domain's thread membership requires synchronous calls 764 into the architecture layer. 765 766 If enabled, the architecture layer must implement the following 767 APIs: 768 769 arch_mem_domain_thread_add 770 arch_mem_domain_thread_remove 771 arch_mem_domain_partition_remove 772 arch_mem_domain_partition_add 773 774 It's important to note that although supervisor threads can be 775 members of memory domains, they have no implications on supervisor 776 thread access to memory. Memory domain APIs may only be invoked from 777 supervisor mode. 778 779 For these reasons, on uniprocessor systems unless memory access 780 policy is managed in separate software constructions like page 781 tables, these APIs don't need to be implemented as the underlying 782 memory management hardware will be reprogrammed on context switch 783 anyway. 784 785menu "SMP Options" 786 787config USE_SWITCH 788 bool "Use new-style _arch_switch instead of arch_swap" 789 depends on USE_SWITCH_SUPPORTED 790 help 791 The _arch_switch() API is a lower level context switching 792 primitive than the original arch_swap mechanism. It is required 793 for an SMP-aware scheduler, or if the architecture does not 794 provide arch_swap. In uniprocess situations where the 795 architecture provides both, _arch_switch incurs more somewhat 796 overhead and may be slower. 797 798config USE_SWITCH_SUPPORTED 799 bool 800 help 801 Indicates whether _arch_switch() API is supported by the 802 currently enabled platform. This option should be selected by 803 platforms that implement it. 804 805config SMP 806 bool "Enable symmetric multithreading support" 807 depends on USE_SWITCH 808 help 809 When true, kernel will be built with SMP support, allowing 810 more than one CPU to schedule Zephyr tasks at a time. 811 812config SMP_BOOT_DELAY 813 bool "Delay booting secondary cores" 814 depends on SMP 815 help 816 By default Zephyr will boot all available CPUs during start up. 817 Select this option to skip this and allow architecture code boot 818 secondary CPUs at a later time. 819 820config MP_NUM_CPUS 821 int "Number of CPUs/cores" 822 default 1 823 range 1 4 824 help 825 Number of multiprocessing-capable cores available to the 826 multicpu API and SMP features. 827 828config SCHED_IPI_SUPPORTED 829 bool 830 help 831 True if the architecture supports a call to 832 arch_sched_ipi() to broadcast an interrupt that will call 833 z_sched_ipi() on other CPUs in the system. Required for 834 k_thread_abort() to operate with reasonable latency 835 (otherwise we might have to wait for the other thread to 836 take an interrupt, which can be arbitrarily far in the 837 future). 838 839config TRACE_SCHED_IPI 840 bool "Enable Test IPI" 841 help 842 When true, it will add a hook into z_sched_ipi(), in order 843 to check if schedule IPI has called or not, for testing 844 purpose. 845 depends on SCHED_IPI_SUPPORTED 846 depends on MP_NUM_CPUS>1 847 848config KERNEL_COHERENCE 849 bool "Place all shared data into coherent memory" 850 depends on ARCH_HAS_COHERENCE 851 default y if SMP && MP_NUM_CPUS > 1 852 select THREAD_STACK_INFO 853 help 854 When available and selected, the kernel will build in a mode 855 where all shared data is placed in multiprocessor-coherent 856 (generally "uncached") memory. Thread stacks will remain 857 cached, as will application memory declared with 858 __incoherent. This is intended for Zephyr SMP kernels 859 running on cache-incoherent architectures only. Note that 860 when this is selected, there is an implicit API change that 861 assumes cache coherence to any memory passed to the kernel. 862 Code that creates kernel data structures in uncached regions 863 may fail strangely. Some assertions exist to catch these 864 mistakes, but not all circumstances can be tested. 865 866endmenu 867 868config TICKLESS_KERNEL 869 bool "Tickless kernel" 870 default y if TICKLESS_CAPABLE 871 depends on TICKLESS_CAPABLE 872 help 873 This option enables a fully event driven kernel. Periodic system 874 clock interrupt generation would be stopped at all times. 875 876config TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 877 bool 878 default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" 879 help 880 Hidden option to signal that toolchain supports generating code 881 with thread local storage. 882 883config THREAD_LOCAL_STORAGE 884 bool "Thread Local Storage (TLS)" 885 depends on ARCH_HAS_THREAD_LOCAL_STORAGE && TOOLCHAIN_SUPPORTS_THREAD_LOCAL_STORAGE 886 select NEED_LIBC_MEM_PARTITION if (CPU_CORTEX_M && USERSPACE) 887 help 888 This option enables thread local storage (TLS) support in kernel. 889 890endmenu 891
