# # For a description of the syntax of this configuration file, # see the file kconfig-language.txt in the NuttX tools repository. # menuconfig DISABLE_OS_API bool "Disable NuttX interfaces" default y ---help--- The following can be used to disable categories of APIs supported by the OS. If the compiler supports weak functions, then it should not be necessary to disable functions unless you want to restrict usage of those APIs. if DISABLE_OS_API config DISABLE_POSIX_TIMERS bool "Disable POSIX timers" default DEFAULT_SMALL ---help--- Disable support for the the entire POSIX timer family including timer_create(), timer_gettime(), timer_settime(), etc. NOTE: This option will also disable getitimer() and setitimer() which are not, strictly speaking, POSIX timers. config DISABLE_PTHREAD bool "Disable pthread support" default DEFAULT_SMALL config DISABLE_MQUEUE bool "Disable POSIX message queue support" default DEFAULT_SMALL config DISABLE_ENVIRON bool "Disable environment variable support" default DEFAULT_SMALL endif # DISABLE_OS_API menu "Clocks and Timers" config ARCH_HAVE_TICKLESS bool config SCHED_TICKLESS bool "Support tick-less OS" default n depends on ARCH_HAVE_TICKLESS ---help--- By default, system time is driven by a periodic timer interrupt. An alternative configurations is a tick-less configuration in which there is no periodic timer interrupt. Instead an interval timer is used to schedule the next OS time event. This option selects that tick-less OS option. If the tick-less OS is selected, then there are additional platform specific interfaces that must be provided as defined in include/nuttx/arch.h if SCHED_TICKLESS config SCHED_TICKLESS_ALARM bool "Tickless alarm" default n ---help--- The tickless option can be supported either via a simple interval timer (plus elapsed time) or via an alarm. The interval timer allows programming events to occur after an interval. With the alarm, you can set a time in the future and get an event when that alarm goes off. This option selects the use of an alarm. The advantage of an alarm is that it avoids some small timing errors; the advantage of the use of the interval timer is that the hardware requirement may be less. config SCHED_TICKLESS_LIMIT_MAX_SLEEP bool "Max sleep period (in microseconds)" default n ---help--- Enables use of the g_oneshot_maxticks variable. This variable is initialized by platform-specific logic at runtime to the maximum delay that the timer can wait (in configured clock ticks). The RTOS tickless logic will then limit all requested delays to this value. endif config USEC_PER_TICK int "System timer tick period (microseconds)" default 10000 if !SCHED_TICKLESS default 100 if SCHED_TICKLESS ---help--- In the "normal" configuration where system time is provided by a periodic timer interrupt, the default system timer is expected to run at 100Hz or USEC_PER_TICK=10000. This setting must be defined to inform of NuttX the interval that the processor hardware is providing system timer interrupts to the OS. If SCHED_TICKLESS is selected, then there are no system timer interrupts. In this case, USEC_PER_TICK does not control any timer rates. Rather, it only determines the resolution of time reported by clock_systime_ticks() and the resolution of times that can be set for certain delays including watchdog timers and delayed work. In this case there is a trade-off: It is better to have the USEC_PER_TICK as low as possible for higher timing resolution. However, the time is currently held in 'unsigned int' on some systems, this may be 16-bits but on most contemporary systems it will be 32-bits. In either case, smaller values of USEC_PER_TICK will reduce the range of values that delays that can be represented. So the trade-off is between range and resolution (you could also modify the code to use a 64-bit value if you really want both). The default, 100 microseconds, will provide for a range of delays up to 120 hours. This value should never be less than the underlying resolution of the timer. Error may ensue. if !SCHED_TICKLESS config SYSTEMTICK_EXTCLK bool "Use external clock" default n depends on ARCH_HAVE_EXTCLK ---help--- Use external clock for system tick. When enabled, the platform-specific logic must start its own timer interrupt to make periodic calls to the nxsched_process_timer() or the functions called within. The purpose is to move the scheduling off the processor clock to allow entering low power states that would disable that clock. config SYSTEMTICK_HOOK bool "System timer hook" default n ---help--- Enable a call to a user-provided, board-level function on each timer tick. This permits custom actions that may be performed on each timer tick. The form of the user-provided function is: void board_timerhook(void); (prototyped in include/nuttx/board.h). endif # !SCHED_TICKLESS config SYSTEM_TIME64 bool "64-bit system clock" default n ---help--- The system timer is incremented at the rate determined by USEC_PER_TICK, typically at 100Hz. The count at any given time is then the "uptime" in units of system timer ticks. By default, the system time is 32-bits wide. Those defaults provide a range of about 497 days which is probably a sufficient range for "uptime". However, if the system timer rate is significantly higher than 100Hz and/or if a very long "uptime" is required, then this option can be selected to support a 64-bit wide timer. config ARCH_HAVE_TIMEKEEPING bool default n config CLOCK_TIMEKEEPING bool "Support timekeeping algorithms" default n depends on ARCH_HAVE_TIMEKEEPING ---help--- CLOCK_TIMEKEEPING enables experimental time management algorithms. config JULIAN_TIME bool "Enables Julian time conversions" default n ---help--- Enables Julian time conversions config START_YEAR int "Start year" default 2018 range 1970 2106 ---help--- NuttX uses an unsigned 32-bit integer for time_t which provides a range from 1970 to 2106. config START_MONTH int "Start month" default 1 range 1 12 config START_DAY int "Start day" default 1 range 1 31 config PREALLOC_TIMERS int "Number of pre-allocated POSIX timers" default 4 if DEFAULT_SMALL default 8 if !DEFAULT_SMALL depends on !DISABLE_POSIX_TIMERS ---help--- The number of pre-allocated POSIX timer structures. The system manages a pool of preallocated timer structures to minimize dynamic allocations. Set to zero for all dynamic allocations. endmenu # Clocks and Timers menu "Tasks and Scheduling" config SPINLOCK bool "Support Spinlocks" default n ---help--- Enables support for spinlocks. Spinlocks are used primarily for synchronization in SMP configurations but are available for general synchronization between CPUs. Use in a single CPU configuration would most likely be fatal. Note, however, that this does not depend on CONFIG_ARCH_HAVE_MULTICPU. This permits the use of spinlocks in other novel architectures. config IRQCHAIN bool "Enable multi handler sharing a IRQ" default n ---help--- Enable support for IRQCHAIN. if IRQCHAIN config PREALLOC_IRQCHAIN int "Number of pre-allocated irq chains" default 4 if DEFAULT_SMALL default 8 if !DEFAULT_SMALL ---help--- The number of pre-allocated irq chain structures. The system manages a pool of preallocated irq chain structures to minimize dynamic allocations. You will, however, get better performance and memory usage if this value is tuned to minimize such allocations. endif # IRQCHAIN config IRQCOUNT bool default n config SMP bool "Symmetric Multi-Processing (SMP)" default n depends on ARCH_HAVE_MULTICPU depends on ARCH_HAVE_TESTSET depends on ARCH_INTERRUPTSTACK != 0 select SPINLOCK select SCHED_RESUMESCHEDULER select IRQCOUNT ---help--- Enables support for Symmetric Multi-Processing (SMP) on a multi-CPU platform. N.B. SMP mode requires the use of ARCH_INTERRUPTSTACK: CPU0 thread0 -> IRQ enter -> add thread0 to block_list -> IRQ leave(crash) || /\ / \ CPU1 thread1 -> block_task -> take thread0 from block_list -> run thread0 CPU0 IRQ handler use thread0's stack, but thread0 may switch to CPU1, that will caused IRQ handler stack corruption. if SMP config SMP_NCPUS int "Number of CPUs" default 4 range 1 32 ---help--- This value identifies the number of CPUs supported by the processor that will be used for SMP. If CONFIG_DEBUG_FEATURES is enabled, then the value one is permitted for CONFIG_SMP_NCPUS. This is not normally a valid setting for an SMP configuration. However, running the SMP logic in a single CPU configuration is useful during certain testing. endif # SMP choice prompt "Initialization Task" default INIT_ENTRY if !BUILD_KERNEL default INIT_FILE if !BINFMT_DISABLE default INIT_NONE if BINFMT_DISABLE config INIT_NONE bool "None" config INIT_ENTRY bool "Via application entry" depends on !BUILD_KERNEL config INIT_FILE bool "Via executable file" depends on !BINFMT_DISABLE endchoice # Initialization task config INIT_ARGS string "Application argument list" depends on !INIT_NONE ---help--- The argument list for user applications. e.g.: "\"arg1\",\"arg2\",\"arg3\"" config INIT_STACKSIZE int "Main thread stack size" default DEFAULT_TASK_STACKSIZE ---help--- The size of the stack to allocate for the user initialization thread that is started as soon as the OS completes its initialization. config INIT_PRIORITY int "init thread priority" default 100 ---help--- The priority of the user initialization thread. if INIT_ENTRY config INIT_ENTRYPOINT string "Application entry point" default "main" ---help--- The name of the entry point for user applications. For the example applications this is of the form 'app_main' where 'app' is the application name. If not defined, INIT_ENTRYPOINT defaults to "main". config INIT_ENTRYNAME string "Application entry name" default INIT_ENTRYPOINT endif # INIT_ENTRY if INIT_FILE config INIT_FILEPATH string "Application initialization path" default "/bin/init" ---help--- The name of the entry point for user applications. For the example applications this is of the form 'app_main' where 'app' is the application name. If not defined, INIT_ENTRYPOINT defaults to "main". config INIT_SYMTAB string "Symbol table" default "NULL" if !EXECFUNCS_HAVE_SYMTAB default EXECFUNCS_SYMTAB_ARRAY if EXECFUNCS_HAVE_SYMTAB depends on BUILD_FLAT ---help--- The name of other global array that holds the exported symbol table. The special string "NULL" may be provided if there is no symbol table. Quotation marks will be stripped when config.h is generated. NOTE: This setting cannot be used in protected or kernel builds. Any kernel mode symbols tables would not be usable for resolving symbols in user mode executables. config INIT_NEXPORTS string "Symbol table size" default "0" if !EXECFUNCS_HAVE_SYMTAB default EXECFUNCS_NSYMBOLS_VAR if EXECFUNCS_HAVE_SYMTAB depends on BUILD_FLAT ---help--- The size of the symbol table. NOTE that is is logically a numeric value but is represent by a string. That allows you to put sizeof(something) or a macro or a global variable name for the symbol table size. Quotation marks will be stripped when config.h is generated. NOTE: This setting cannot be used in protected or kernel builds. Any kernel mode symbols tables would not be usable for resolving symbols in user mode executables. menuconfig INIT_MOUNT bool "Auto-mount init file system" default n depends on !DISABLE_MOUNTPOINT ---help--- In order to use the the initial startup program when CONFIG_INIT_FILEPATH is provided, it is necessary to mount the initial file system that provides init program. Normally this mount is done in the board-specific initialization logic. However, if the mount is very simple, it can be performed by the OS bring-up logic itself by selecting this option. if INIT_MOUNT config INIT_MOUNT_SOURCE string "The block device to mount" default "/dev/ram0" config INIT_MOUNT_TARGET string "Path to the mounted file system" default "/bin" config INIT_MOUNT_FSTYPE string "The file system type to mount" default "romfs" config INIT_MOUNT_FLAGS hex "Flags passed to mount" default 0 config INIT_MOUNT_DATA string "Additional data passed to mount" default "" endif # INIT_MOUNT endif # INIT_FILE config RR_INTERVAL int "Round robin timeslice (MSEC)" default 0 ---help--- The round robin timeslice will be set this number of milliseconds; Round robin scheduling (SCHED_RR) is enabled by setting this interval to a positive, non-zero value. config SCHED_SPORADIC bool "Support sporadic scheduling" default n select SCHED_SUSPENDSCHEDULER select SCHED_RESUMESCHEDULER ---help--- Build in additional logic to support sporadic scheduling (SCHED_SPORADIC). if SCHED_SPORADIC config SCHED_SPORADIC_MAXREPL int "Maximum number of replenishments" default 3 range 1 255 ---help--- Controls the size of allocated replenishment structures and, hence, also limits the maximum number of replenishments. config SPORADIC_INSTRUMENTATION bool "Sporadic scheduler monitor hooks" default n ---help--- Enables instrumentation in the sporadic scheduler to monitor scheduler behavior. If enabled, then the board-specific logic must provide the following functions: void arch_sporadic_start(FAR struct tcb_s *tcb); void arch_sporadic_lowpriority(FAR struct tcb_s *tcb); void arch_sporadic_suspend(FAR struct tcb_s *tcb); void arch_sporadic_resume(FAR struct tcb_s *tcb); endif # SCHED_SPORADIC config TASK_NAME_SIZE int "Maximum task name size" default 31 ---help--- Specifies the maximum size of a task name to save in the TCB. Useful if scheduler instrumentation is selected. Set to zero to disable. Excludes the NUL terminator; the actual allocated size will be TASK_NAME_SIZE + 1. The default of 31 then results in a align-able 32-byte allocation. config SCHED_HAVE_PARENT bool "Support parent/child task relationships" default n ---help--- Remember the ID of the parent task when a new child task is created. This support enables some additional features (such as SIGCHLD) and modifies the behavior of other interfaces. For example, it makes waitpid() more standards complete by restricting the waited-for tasks to the children of the caller. Default: disabled. config SCHED_CHILD_STATUS bool "Retain child exit status" default n depends on SCHED_HAVE_PARENT ---help--- If this option is selected, then the exit status of the child task will be retained after the child task exits. This option should be selected if you require knowledge of a child process's exit status. Without this setting, wait(), waitpid() or waitid() may fail. For example, if you do: 1) Start child task 2) Wait for exit status (using wait(), waitpid(), or waitid()). This can fail because the child task may run to completion before the wait begins. There is a non-standard work-around in this case: The above sequence will work if you disable pre-emption using sched_lock() prior to starting the child task, then re-enable pre- emption with sched_unlock() after the wait completes. This works because the child task is not permitted to run until the wait is in place. The standard solution would be to enable SCHED_CHILD_STATUS. In this case the exit status of the child task is retained after the child exits and the wait will successful obtain the child task's exit status whether it is called before the child task exits or not. Warning: If you enable this feature, then your application must either (1) take responsibility for reaping the child status with wait(), waitpid(), or waitid(), or (2) suppress retention of child status. If you do not reap the child status, then you have a memory leak and your system will eventually fail. Retention of child status can be suppressed on the parent using logic like: struct sigaction sa; sa.sa_handler = SIG_IGN; sa.sa_flags = SA_NOCLDWAIT; int ret = sigaction(SIGCHLD, &sa, NULL); if SCHED_CHILD_STATUS config PREALLOC_CHILDSTATUS int "Number of pre-allocated child status" default 0 ---help--- To prevent runaway child status allocations and to improve allocation performance, child task exit status structures are pre- allocated when the system boots. This setting determines the number of child status structures that will be pre-allocated. However, the number of child status structures may need to be significantly larger because this number includes the maximum number of tasks that are running PLUS the number of tasks that have exit'ed without having their exit status reaped (via wait(), waitid(), or waitpid()). Obviously, if tasks spawn children indefinitely and never have the exit status reaped, then you may have a memory leak! If you enable the SCHED_CHILD_STATUS feature, then your application must take responsibility for either (1) reaping the child status with wait(), waitpid(), or waitid() or it must (2) suppress retention of child status. Otherwise, your system will eventually fail. Retention of child status can be suppressed on the parent using logic like: struct sigaction sa; sa.sa_handler = SIG_IGN; sa.sa_flags = SA_NOCLDWAIT; int ret = sigaction(SIGCHLD, &sa, NULL); config DEBUG_CHILDSTATUS bool "Enable Child Status Debug Output" default n depends on SCHED_CHILD_STATUS && DEBUG_FEATURES ---help--- Very detailed... I am sure that you do not want this. endif # SCHED_CHILD_STATUS config SCHED_WAITPID bool "Enable waitpid() API" default n ---help--- Enables the waitpid() interface in a default, non-standard mode (non-standard in the sense that the waited for PID need not be child of the caller). If SCHED_HAVE_PARENT is also defined, then this setting will modify the behavior or waitpid() (making more spec compliant) and will enable the waitid() and wait() interfaces as well. config SCHED_USER_IDENTITY bool "Support per-task User Identity" default n ---help--- This selection enables functionality of getuid(), setuid(), getgid(), setgid(). If this option is not selected, then stub, root-only versions of these interfaces are available. When selected, these interfaces will associate a UID and/or GID with each task group. Those can then be managed using the interfaces. Child tasks will inherit the UID and GID of its parent. config SCHED_THREAD_LOCAL bool "Support __thread/thread_local keyword" default n depends on ARCH_HAVE_THREAD_LOCAL ---help--- This option enables architecture-specific TLS support (__thread/thread_local keyword) Note: Toolchain must be compiled with '--enable-tls' enabled endmenu # Tasks and Scheduling menu "Pthread Options" depends on !DISABLE_PTHREAD config PTHREAD_MUTEX_TYPES bool "Enable mutex types" default n ---help--- Set to enable support for recursive and errorcheck mutexes. Enables pthread_mutexattr_settype(). choice prompt "pthread mutex robustness" default PTHREAD_MUTEX_ROBUST if !DEFAULT_SMALL default PTHREAD_MUTEX_UNSAFE if DEFAULT_SMALL config PTHREAD_MUTEX_ROBUST bool "Robust mutexes" ---help--- Support only the robust form of the NORMAL mutex. config PTHREAD_MUTEX_UNSAFE bool "Traditional unsafe mutexes" ---help--- Support only the traditional non-robust form of the NORMAL mutex. You should select this option only for backward compatibility with software you may be porting or, perhaps, if you are trying to minimize footprint. config PTHREAD_MUTEX_BOTH bool "Both robust and unsafe mutexes" ---help--- Support both forms of NORMAL mutexes. endchoice # pthread mutex robustness choice prompt "Default NORMAL mutex robustness" default PTHREAD_MUTEX_DEFAULT_ROBUST depends on PTHREAD_MUTEX_BOTH config PTHREAD_MUTEX_DEFAULT_ROBUST bool "Robust default" ---help--- The default is robust NORMAL mutexes (non-standard) config PTHREAD_MUTEX_DEFAULT_UNSAFE bool "Unsafe default" ---help--- The default is traditional unsafe NORMAL mutexes (standard) endchoice # Default NORMAL mutex robustness choice prompt "Default pthread mutex protocol" default PTHREAD_MUTEX_DEFAULT_PRIO_NONE config PTHREAD_MUTEX_DEFAULT_PRIO_NONE bool "PTHREAD_PRIO_NONE default" ---help--- By default, pthread mutexes utilize PTHREAD_PRIO_NONE protocol (standard). config PTHREAD_MUTEX_DEFAULT_PRIO_INHERIT bool "PTHREAD_PRIO_INHERIT default" depends on PRIORITY_INHERITANCE ---help--- By default, pthread mutexes utilize PTHREAD_PRIO_INHERIT protocol (POSIX non-standard but a reasonable choice for most real-time systems). endchoice # Default pthread mutex protocol config PTHREAD_CLEANUP bool "pthread cleanup stack" default n ---help--- Select to enable support for pthread exit cleanup stacks. This enables the interfaces pthread_cleanup_push() and pthread_cleanup_pop(). config PTHREAD_CLEANUP_STACKSIZE int "pthread cleanup stack size" default 1 range 1 32 depends on PTHREAD_CLEANUP ---help--- The maximum number of cleanup actions that may be pushed by pthread_clean_push(). This setting will increase the size of EVERY pthread task control block by about n * CONFIG_PTHREAD_CLEANUP_STACKSIZE where n is the size of a pointer, 2 * sizeof(uintptr_t), this would be 8 for a CPU with 32-bit addressing and 4 for a CPU with 16-bit addressing. config CANCELLATION_POINTS bool "Cancellation points" default n ---help--- Enable POSIX cancellation points for pthread_cancel(). If selected, cancellation points will also used with the task_delete() API even if pthreads are not enabled. endmenu # Pthread Options menu "Performance Monitoring" config SCHED_SUSPENDSCHEDULER bool default n config SCHED_RESUMESCHEDULER bool default n config SCHED_IRQMONITOR bool "Enable IRQ monitoring" default n depends on FS_PROCFS ---help--- Enabling counting of interrupts from all interrupt sources. These counts will be available in the mounted procfs file systems at the top-level file, "irqs". config SCHED_CRITMONITOR bool "Enable Critical Section monitoring" default n depends on FS_PROCFS select SCHED_SUSPENDSCHEDULER select SCHED_RESUMESCHEDULER select IRQCOUNT ---help--- Enables logic that monitors the duration of time that a thread keeps interrupts or pre-emption disabled. These global locks can have negative consequences to real time performance: Disabling interrupts adds jitter in the time when an interrupt request is asserted until the hardware can respond with the interrupt. Disabling pre-emption adds jitter in the time from when the event is posted in the interrupt handler until the task that responds to the event can run. if SCHED_CRITMONITOR config SCHED_CRITMONITOR_MAXTIME_THREAD int "THREAD max execution time" default 0 ---help--- Thread execution time should be smaller than SCHED_CRITMONITOR_MAXTIME_THREAD, or system will give a warning. For debugging system latency, 0 means disabled. config SCHED_CRITMONITOR_MAXTIME_WQUEUE int "WORK queue max execution time" default SCHED_CRITMONITOR_MAXTIME_THREAD ---help--- Worker execution time should be smaller than SCHED_CRITMONITOR_MAXTIME_WQUEUE, or system will give a warning. For debugging system latency, 0 means disabled. config SCHED_CRITMONITOR_MAXTIME_PREEMPTION int "Pre-emption (sched_lock) max holding time" default SCHED_CRITMONITOR_MAXTIME_WQUEUE ---help--- Pre-emption holding time should be smaller than SCHED_CRITMONITOR_MAXTIME_PREEMPTION, or system will give a warning. For debugging system latency, 0 means disabled. config SCHED_CRITMONITOR_MAXTIME_CSECTION int "Csection (enter_critical_section) max holding time" default SCHED_CRITMONITOR_MAXTIME_PREEMPTION ---help--- Csection holding time should be smaller than SCHED_CRITMONITOR_MAXTIME_CSECTION, or system will give a warning. For debugging system latency, 0 means disabled. config SCHED_CRITMONITOR_MAXTIME_IRQ int "IRQ max execution time" default SCHED_CRITMONITOR_MAXTIME_CSECTION ---help--- IRQ handler execution time should be smaller than SCHED_CRITMONITOR_MAXTIME_IRQ, or system will give a warning. For debugging system latency, 0 means disabled. config SCHED_CRITMONITOR_MAXTIME_WDOG int "WDOG callback max execution time" default SCHED_CRITMONITOR_MAXTIME_IRQ ---help--- Wdog callback execution time should be smaller than SCHED_CRITMONITOR_MAXTIME_WDOG, or system will give a warning. For debugging system latency, 0 means disabled. endif # SCHED_CRITMONITOR config SCHED_CPULOAD bool "Enable CPU load monitoring" default n select SCHED_CPULOAD_EXTCLK if SCHED_TICKLESS ---help--- If this option is selected, the timer interrupt handler will monitor if the system is IDLE or busy at the time of that the timer interrupt occurs. This is a very coarse measurement, but over a period of time, it can very accurately determine the percentage of the time that the CPU is IDLE. The statistics collected in this could be used, for example, in the PROCFS file system to provide CPU load measurements when read. Note that in tickless mode of operation (SCHED_TICKLESS) there is no system timer interrupt and CPU load measurements will not be possible unless you provide an alternative clock to drive the sampling and select SCHED_CPULOAD_EXTCLK. if SCHED_CPULOAD config SCHED_CPULOAD_EXTCLK bool "Use external clock" default n ---help--- The CPU load measurements are determined by sampling the active tasks periodically at the occurrence to a timer expiration. By default, the system clock is used to do that sampling. There is a serious issue for the accuracy of measurements if the system clock is used, however. NuttX threads are often started at the time of the system timer expiration. Others may be stopped at the time of the system timer expiration (if round-robin time-slicing is enabled). Such thread behavior occurs synchronously with the system timer and, hence, is not randomly sampled. As a consequence, the CPU load attributed to these threads that run synchronously with they system timer may be grossly in error. The solution is to use some other clock that runs at a different rate and has timer expirations that are asynchronous with the system timer. Then truly accurate load measurements can be achieved. This option enables use of such an "external" clock. The implementation of the clock must be provided by platform-specific logic; that platform-specific logic must call the system function nxsched_process_cpuload_ticks() at each timer expiration with interrupts disabled. if SCHED_CPULOAD_EXTCLK config SCHED_CPULOAD_TICKSPERSEC int "External clock rate" default 100 ---help--- If an external clock is used to drive the sampling for the CPU load calculations, then this value must be provided. This value provides the rate of the external clock interrupts in units of ticks per second. The default value of 100 corresponds to a 100Hz clock. NOTE: that 100Hz is the default frequency of the system time and, hence, the worst possible choice in most cases. choice prompt "Select CPU load timer" default CPULOAD_ONESHOT config CPULOAD_ONESHOT bool "Use Oneshot timer" ---help--- Use an MCU-specific oneshot timer as the external clock. The oneshot timer must be configured by board specific logic which must then call: void nxsched_oneshot_extclk(FAR struct oneshot_lowerhalf_s *lower); To start the CPU load measurement. See include/nuttx/clock.h NOTE that in this configuration, CONFIG_SCHED_CPULOAD_TICKSPERSEC is the sample rate that will be accomplished by programming the oneshot time repeatedly. If CPULOAD_ONESHOT_ENTROPY is also selected, then the underly frequency driving the oneshot timer must be significantly faster than CONFIG_SCHED_CPULOAD_TICKSPERSE to permit precise modulation the sample periods. config CPULOAD_PERIOD bool "Use Period timer" ---help--- Use an MCU-specific period timer as the external clock. The period timer must be configured by board specific logic which must then call: void nxsched_period_extclk(FAR struct timer_lowerhalf_s *lower); To start the CPU load measurement. See include/nuttx/clock.h NOTE that in this configuration, CONFIG_SCHED_CPULOAD_TICKSPERSEC is the sample rate that will be accomplished by programming the period time. endchoice config CPULOAD_ENTROPY int "Bits of entropy" default 6 range 0 30 ---help--- This is the number of bits of entropy that will be applied. The oneshot will be set to this interval: CPULOAD_ONESHOT_NOMINAL - (CPULOAD_ONESHOT_ENTROPY / 2) + error + nrand(CPULOAD_ONESHOT_ENTROPY) Where CPULOAD_ONESHOT_NOMINAL is the nominal sample interval implied by CONFIG_SCHED_CPULOAD_TICKSPERSEC in units of microseconds. CPULOAD_ONESHOT_ENTROPY is (1 << CONFIG_CPULOAD_ENTROPY), and 'error' is an error value that is retained from interval to interval so that although individual intervals are randomized, the average will still be CONFIG_SCHED_CPULOAD_TICKSPERSEC. This special value of zero disables entropy. endif # SCHED_CPULOAD_EXTCLK config SCHED_CPULOAD_TIMECONSTANT int "CPU load time constant" default 2 ---help--- The accumulated CPU count is divided by two when the accumulated tick count exceeds this time constant. This time constant is in units of seconds. endif # SCHED_CPULOAD config SCHED_INSTRUMENTATION bool "System performance monitor hooks" default n select SCHED_SUSPENDSCHEDULER select SCHED_RESUMESCHEDULER ---help--- Enables instrumentation in scheduler to monitor system performance. If enabled, then the board-specific logic must provide the following functions (see include/sched.h): void sched_note_start(FAR struct tcb_s *tcb); void sched_note_stop(FAR struct tcb_s *tcb); If CONFIG_SMP is enabled, then these additional interfaces are expected: void sched_note_cpu_start(FAR struct tcb_s *tcb, int cpu); void sched_note_cpu_started(FAR struct tcb_s *tcb); if SCHED_INSTRUMENTATION config SCHED_INSTRUMENTATION_SWITCH bool "Use note switch for instrumentation" default n ---help--- Use note switch for instrumentation. void sched_note_suspend(FAR struct tcb_s *tcb); void sched_note_resume(FAR struct tcb_s *tcb); If CONFIG_SMP is enabled, then these additional interfaces are expected: void sched_note_cpu_pause(FAR struct tcb_s *tcb, int cpu); void sched_note_cpu_paused(FAR struct tcb_s *tcb); void sched_note_cpu_resume(FAR struct tcb_s *tcb, int cpu); void sched_note_cpu_resumed(FAR struct tcb_s *tcb); NOTE: These are internal OS interfaces and are called at very critical locations in the OS. There is very little that can be done in these interfaces. For example, normal devices may not be used; syslog output cannot be performed. config SCHED_INSTRUMENTATION_EXTERNAL bool "System performance monitor endpoints are external" default n ---help--- When this option is enabled, the board specific logic must implement all callbacks listed in SCHED_INSTRUMENTATION, SCHED_INSTRUMENTATION_CSECTION, SCHED_INSTRUMENTATION_SPINLOCKS, SCHED_INSTRUMENTATION_SYSCALL and SCHED_INSTRUMENTATION_IRQHANDLER. Otherwise the common code will implement these callbacks and packet the arguments into note_ struct. Then the board -specific logic just needs to implement one callback: void sched_note_add(FAR const void *note, size_t notelen); and send the data to the suitable transport hardware. config SCHED_INSTRUMENTATION_CPUSET hex "CPU bit set" default 0xffff depends on SMP && SCHED_INSTRUMENTATION_FILTER ---help--- Monitor only CPUs in the bitset. Bit 0=CPU0, Bit1=CPU1, etc. config SCHED_INSTRUMENTATION_PREEMPTION bool "Preemption monitor hooks" default n ---help--- Enables additional hooks for changes to pre-emption state. Board- specific logic must provide this additional logic. void sched_note_premption(FAR struct tcb_s *tcb, bool state); config SCHED_INSTRUMENTATION_CSECTION bool "Critical section monitor hooks" default n select IRQCOUNT ---help--- Enables additional hooks for entry and exit from critical sections. Interrupts are disabled while within a critical section. Board- specific logic must provide this additional logic. void sched_note_csection(FAR struct tcb_s *tcb, bool state); config SCHED_INSTRUMENTATION_SPINLOCKS bool "Spinlock monitor hooks" default n ---help--- Enables additional hooks for spinlock state. Board-specific logic must provide this additional logic. void sched_note_spinlock(FAR struct tcb_s *tcb, bool state); void sched_note_spinlocked(FAR struct tcb_s *tcb, bool state); void sched_note_spinunlock(FAR struct tcb_s *tcb, bool state); void sched_note_spinabort(FAR struct tcb_s *tcb, bool state); config SCHED_INSTRUMENTATION_SYSCALL bool "System call monitor hooks" default n depends on ARCH_HAVE_SYSCALL_HOOKS ---help--- Enables additional hooks for entry and exit from system call. Board-specific logic must provide this additional logic. void sched_note_syscall_enter(int nr, int argc, ...); void sched_note_syscall_leave(int nr, uintptr_t result); config SCHED_INSTRUMENTATION_IRQHANDLER bool "Interrupt handler monitor hooks" default n ---help--- Enables additional hooks for interrupt handler. Board-specific logic must provide this additional logic. void sched_note_irqhandler(int irq, FAR void *handler, bool enter); config SCHED_INSTRUMENTATION_DUMP bool "Use note dump for instrumentation" default n ---help--- Use note dump for instrumentation. void sched_note_string(FAR const char *buf); void sched_note_dump(uint32_t module, uint8_t event, FAR const void *buf, size_t len); void sched_note_vprintf(FAR const char *fmt, va_list va); void sched_note_vbprintf(uint32_t module, uint8_t event, FAR const char *fmt, va_list va); void sched_note_printf(FAR const char *fmt, ...) printflike(1, 2); void sched_note_bprintf(uint32_t module, uint8_t event, FAR const char *fmt, ...); config SCHED_INSTRUMENTATION_HIRES bool "Use Hi-Res RTC for instrumentation" default n ---help--- Use higher resolution system timer for instrumentation. config SCHED_INSTRUMENTATION_FILTER bool "Instrumenation filter" default n ---help--- Enables the filter logic for the instrumentation. If this option is enabled, the instrumentation data passed to sched_note_add() can be filtered by syscall and IRQ number. The filter logic can be configured by sched_note_filter APIs defined in include/nuttx/sched_note.h. config SCHED_INSTRUMENTATION_FILTER_DEFAULT_MODE hex "Default instrumentation filter mode" depends on SCHED_INSTRUMENTATION_FILTER default 0x3f ---help--- Default mode of the instrumentation filter logic. Bit 0 = Enable instrumentation Bit 1 = Enable switch instrumentation Bit 2 = Enable syscall instrumentation Bit 3 = Enable IRQ instrumentation Bit 4 = Enable dump instrumentation Bit 5 = Enable collecting syscall arguments endif # SCHED_INSTRUMENTATION endmenu # Performance Monitoring menu "Files and I/O" config DEV_CONSOLE bool "Enable /dev/console" default y ---help--- Set if architecture-specific logic provides /dev/console at boot-up time. Enables stdout, stderr, stdin in the start-up application. You need this setting if your console device is ready at boot time. For example, if you are using a serial console, then /dev/console (aka, /dev/ttyS0) will be available when the application first starts. You must not select DEV_CONSOLE if you console device comes up later and is not ready until after the application starts. At this time, the only console device that behaves this way is a USB serial console. When the application first starts, the USB is (probably) not yet connected and /dev/console will not be created until later when the host connects to the USB console. config FDCLONE_DISABLE bool "Disable cloning of file descriptors" default n ---help--- Disable cloning of all file descriptors by task_create() when a new ask is started. If set, all files/drivers will appear to be closed in the new task. config FDCLONE_STDIO bool "Disable clone file descriptors without stdio" default n ---help--- Disable cloning of all but the first three file descriptors (stdin, stdout, stderr) by task_create() when a new task is started. If set, all files/drivers will appear to be closed in the new task except for stdin, stdout, and stderr. config NFILE_DESCRIPTORS_PER_BLOCK int "The number of file descriptors per block" default 8 range 3 99999 ---help--- The number of file descriptors per block(one for each open) config FILE_STREAM bool "Enable FILE stream" default y ---help--- Enable the standard buffered input/output support config NAME_MAX int "Maximum size of a file name" default 32 ---help--- The maximum size of a file name. config PATH_MAX int "Maximum size of path name" default 256 ---help--- The maximum size of path name. endmenu # Files and I/O menuconfig PRIORITY_INHERITANCE bool "Enable priority inheritance" default n ---help--- Set to enable support for priority inheritance on mutexes and semaphores. When this option is enabled, the initial configuration of all seamphores and mutexes will be with priority inheritance enabled. That configuration may not be appropriate in all cases (such as when the semaphore or mutex is used for signaling). In such cases, priority inheritance can be disabled for individual semaphores by calling: int ret = sem_setprotocol(&sem, SEM_PRIO_NONE); From applications, the functionally equivalent OS internal interface, nxsem_set_protocol(), should be used within the OS And for individual pthread mutexes by setting the protocol attribute before initializing the mutex: int ret = pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_NONE); if PRIORITY_INHERITANCE config SEM_PREALLOCHOLDERS int "Number of pre-allocated holders" default 4 if DEFAULT_SMALL default 8 if !DEFAULT_SMALL ---help--- This setting is only used if priority inheritance is enabled. It defines the maximum number of different threads (minus one) that can take counts on a semaphore with priority inheritance support. This may be set to zero if priority inheritance is disabled OR if you are only using semaphores as mutexes (only one holder) OR if no more than two threads participate using a counting semaphore. config SEM_NNESTPRIO int "Maximum number of higher priority threads" default 16 ---help--- If priority inheritance is enabled, then this setting is the maximum number of higher priority threads (minus 1) than can be waiting for another thread to release a count on a semaphore. This value may be set to zero if no more than one thread is expected to wait for a semaphore. endif # PRIORITY_INHERITANCE menu "RTOS hooks" config BOARD_EARLY_INITIALIZE bool "Custom board early initialization" default n ---help--- There are three points in time where you can insert custom, board-specific initialization logic: 1) _board_initialize(): This function is used only for initialization of very low-level things like configuration of GPIO pins, power setting. The OS has not been initialized at this point, so you cannot allocate memory or initialize device drivers at this phase. 2) The next level of initialization is performed by a call to up_initialize() (in arch//src/common/up_initialize.c). The OS has been initialized at this point and it is okay to initialize drivers in this phase. At this same point in time, the OS will also call a board- specific initialization function named board_early_initialize() if CONFIG_BOARD_EARLY_INITIALIZE is selected. The context in which board_early_initialize() executes is suitable for early initialization of most, simple device drivers and is a logical, board-specific extension of up_initialize(). board_early_initialize() runs on the startup, initialization thread. Some initialization operations cannot be performed on the start-up, initialization thread. That is because the initialization thread cannot wait for event. Waiting may be required, for example, to mount a file system or or initialize a device such as an SD card. For this reason, such driver initialize must be deferred to board_late_initialize(). 3) And, finally, just before the user application code starts. If CONFIG_BOARD_LATE_INITIALIZE is selected, then an additional initialization call will be performed in the boot-up sequence to a function called board_late_initialize(). board_late_initialize() will be called after up_initialize() is called and just before the main application is started. This additional initialization phase may be used, for example, to initialize more complex, board-specific device drivers. Waiting for events, use of I2C, SPI, etc are permissible in the context of board_late_initialize(). That is because board_late_initialize() will run on a temporary, internal kernel thread. config BOARD_LATE_INITIALIZE bool "Custom board late initialization" default n ---help--- There are three points in time where you can insert custom, board-specific initialization logic: 1) _board_initialize(): This function is used only for initialization of very low-level things like configuration of GPIO pins, power setting. The OS has not been initialized at this point, so you cannot allocate memory or initialize device drivers at this phase. 2) The next level of initialization is performed by a call to up_initialize() (in arch//src/common/up_initialize.c). The OS has been initialized at this point and it is okay to initialize drivers in this phase. At this same point in time, the OS will also call a board- specific initialization function named board_early_initialize() if CONFIG_BOARD_EARLY_INITIALIZE is selected. The context in which board_early_initialize() executes is suitable for early initialization of most, simple device drivers and is a logical, board-specific extension of up_initialize(). board_early_initialize() runs on the startup, initialization thread. Some initialization operations cannot be performed on the start-up, initialization thread. That is because the initialization thread cannot wait for event. Waiting may be required, for example, to mount a file system or or initialize a device such as an SD card. For this reason, such driver initialize must be deferred to board_late_initialize(). 3) And, finally, just before the user application code starts. If CONFIG_BOARD_LATE_INITIALIZE is selected, then an additional initialization call will be performed in the boot-up sequence to a function called board_late_initialize(). board_late_initialize() will be called after up_initialize() is called and just before the main application is started. This additional initialization phase may be used, for example, to initialize more complex, board-specific device drivers. Waiting for events, use of I2C, SPI, etc are permissible in the context of board_late_initialize(). That is because board_late_initialize() will run on a temporary, internal kernel thread. if BOARD_LATE_INITIALIZE config BOARD_INITTHREAD_STACKSIZE int "Board initialization thread stack size" default DEFAULT_TASK_STACKSIZE ---help--- The size of the stack to allocate when starting the board initialization thread. config BOARD_INITTHREAD_PRIORITY int "Board initialization thread priority" default 240 ---help--- The priority of the board initialization thread. This priority is not a critical setting. No other application threads will be started until the board initialization is completed. Hence, there is very little competition for the CPU. endif # BOARD_LATE_INITIALIZE config SCHED_STARTHOOK bool "Enable startup hook" default n ---help--- Enable a non-standard, internal OS API call nxtask_starthook(). nxtask_starthook() registers a function that will be called on task startup before that actual task entry point is called. The starthook is useful, for example, for setting up automatic configuration of C++ constructors. endmenu # RTOS hooks menu "Signal Configuration" config SIG_PREALLOC_IRQ_ACTIONS int "Number of pre-allocated irq actions" default 4 if DEFAULT_SMALL default 8 if !DEFAULT_SMALL ---help--- The number of pre-allocated irq action structures. config SIG_EVTHREAD bool "Support SIGEV_THREAD" default n depends on !BUILD_KERNEL && SCHED_WORKQUEUE select LIBC_USRWORK if BUILD_PROTECTED ---help--- Built in support for the SIGEV_THREAD signal deliver method. NOTE: The current implementation uses a work queue to notify the client. This, however, would only work in the FLAT build. A different mechanism would need to be development to support this feature on the PROTECTED or KERNEL build. config SIG_EVTHREAD_HPWORK bool "SIGEV_EVTHREAD use HPWORK" default n depends on SIG_EVTHREAD && SCHED_HPWORK ---help--- if selected, SIGEV_THREAD will use the high priority work queue. If not, it will use the low priority work queue (if available). REVISIT: This solution is non-optimal. Some notifications should be high priority and others should be lower priority. Ideally, you should be able to determine which work queue is used on a notification-by-notification basis. menuconfig SIG_DEFAULT bool "Default signal actions" default n ---help--- Enable to support default signal actions. if SIG_DEFAULT comment "Per-signal Default Actions" config SIG_SIGUSR1_ACTION bool "SIGUSR1" default n ---help--- Enable the default action for SIGUSR1 (terminate the task) Make sure that your applications are expecting this POSIX behavior. Backward compatible behavior would require that the application use sigaction() to ignore SIGUSR1. config SIG_SIGUSR2_ACTION bool "SIGUSR2" default n ---help--- Enable the default action for SIGUSR2 (terminate the task) Make sure that your applications are expecting this POSIX behavior. Backward compatible behavior would require that the application use sigaction() to ignore SIGUSR2. config SIG_SIGALRM_ACTION bool "SIGALRM" default n ---help--- Enable the default action for SIGALRM (terminate the task) Make sure that your applications are expecting this POSIX behavior. Backward compatible behavior would require that the application use sigaction() to ignore SIGALRM. config SIG_SIGPOLL_ACTION bool "SIGPOLL" default n depends on FS_AIO ---help--- Enable the default action for SIGPOLL (terminate the task) Make sure that your applications are expecting this POSIX behavior. Backward compatible behavior would require that the application use sigaction() to ignore SIGPOLL. config SIG_SIGSTOP_ACTION bool "SIGSTOP SIGTSTP, and SIGCONT" default y ---help--- Enable the default action for SIGSTOP and SIGTSTP (suspend the task) and SIGCONT (resume the task). config SIG_SIGKILL_ACTION bool "SIGINT SIGKILL SIGQUIT and SIGTERM" default y ---help--- Enable the default action for SIGINT and SIGKILL (terminate the task). config SIG_SIGPIPE_ACTION bool "SIGPIPE" default y ---help--- Enable the default action for SIGPIPE (terminate the task). endif # SIG_DEFAULT menu "Signal Numbers" comment "Standard Signal Numbers" config SIG_SIGUSR1 int "SIGUSR1" default 1 ---help--- Value of standard user signal 1 (SIGUSR1). Default: 1 config SIG_SIGUSR2 int "SIGUSR2" default 2 ---help--- Value of standard user signal 2 (SIGUSR2). Default: 2 config SIG_SIGALRM int "SIGALRM" default 3 ---help--- Default the signal number used with POSIX timers (SIGALRM). Default: 3 config SIG_SIGCHLD int "SIGCHLD" default 4 depends on SCHED_HAVE_PARENT ---help--- The SIGCHLD signal is sent to the parent of a child process when it exits, is interrupted (stopped), or resumes after being interrupted. Default: 4 config SIG_POLL int "SIGPOLL" default 5 depends on FS_AIO ---help--- The SIGPOLL signal is sent to a process when an asynchronous I/O event occurs (meaning it has been polled). Default: 5 if SIG_DEFAULT config SIG_STOP int "SIGSTOP" default 6 ---help--- Suspend/pause a task. SIGSTOP may not be caught or ignored. config SIG_TSTP int "SIGTSTP" default 7 ---help--- Suspend/pause a task. Unlike SIGSTOP, this signal can be caught or ignored. config SIG_CONT int "SIGCONT" default 8 ---help--- Resume a suspended/paused task. SIGSTOP only has an action when send to a stopped task. SIGCONT is ignored by other task. SIGCONT may not be caught or ignored by a stopped task. config SIG_KILL int "SIGKILL" default 9 ---help--- The SIGKILL signal is sent to cause a task termination event. SIGKILL may not be caught or ignored. config SIG_INT int "SIGINT" default 10 ---help--- The SIGINT signal is sent to cause a task termination event. SIGINT may be ignored or caught by the receiving task. config SIG_QUIT int "SIGQUIT" default 11 ---help--- The SIGINT signal is sent to cause a task termination event. SIGQUIT may be ignored or caught by the receiving task. config SIG_TERM int "SIGTERM" default 12 ---help--- The SIGINT signal is sent to cause a task termination event. SIGTERM may be ignored or caught by the receiving task. endif # SIG_DEFAULT config SIG_PIPE int "SIGPIPE" default 13 ---help--- The SIGPIPE signal is sent to a task termination event. This signal is generated when write on a pipe with no one to read it. SIGPIPE may be ignored. config SIG_HUP int "SIGHUP" default 14 ---help--- The SIGHUP would be sent to programs when the serial line was dropped, often because the connected user terminated the connection by hanging up the modem. The system would detect the line was dropped via the lost Data Carrier Detect (DCD) signal. config SIG_TTIN int "SIGTTIN" default 15 ---help--- A process cannot read from the user’s terminal while it is running as a background job. When any process in a background job tries to read from the terminal, all of the processes in the job are sent a SIGTTIN signal. The default action for this signal is to stop the process. For more information about how this interacts with the terminal driver, see Access to the Controlling Terminal. comment "Non-standard Signal Numbers" config SIG_SIGCONDTIMEDOUT int "SIGCONDTIMEDOUT" default 16 depends on !DISABLE_PTHREAD ---help--- This non-standard signal number is used the implementation of pthread_cond_timedwait(). Default 16. config SIG_SIGWORK int "SIGWORK" default 17 depends on SCHED_WORKQUEUE || LIBC_USRWORK ---help--- SIGWORK is a non-standard signal used to wake up various internal NuttX worker threads. This setting specifies the signal number that will be used for SIGWORK. Default: 17 endmenu # Signal Numbers endmenu # Signal Configuration menu "POSIX Message Queue Options" depends on !DISABLE_MQUEUE config PREALLOC_MQ_MSGS int "Number of pre-allocated messages" default 4 if DEFAULT_SMALL default 8 if !DEFAULT_SMALL ---help--- The number of pre-allocated message structures. The system manages a pool of preallocated message structures to minimize dynamic allocations config PREALLOC_MQ_IRQ_MSGS int "Number of pre-allocated irq messages" default 4 if DEFAULT_SMALL default 8 if !DEFAULT_SMALL ---help--- The number of pre-allocated irq message structures. config MQ_MAXMSGSIZE int "Maximum message size" default 32 ---help--- Message structures are allocated with a fixed payload size given by this setting (does not include other message structure overhead. config DISABLE_MQUEUE_NOTIFICATION bool "Disable POSIX message queue notification" default DEFAULT_SMALL ---help--- Disable POSIX message queue notification endmenu # POSIX Message Queue Options config MODULE bool "Enable loadable OS modules" default n select LIBC_MODLIB select ARCH_USE_TEXT_HEAP if ARCH_HAVE_TEXT_HEAP ---help--- Enable support for loadable OS modules. Default: n menu "Work queue support" config SCHED_WORKQUEUE # bool "Enable worker thread" bool default n ---help--- Create dedicated "worker" threads to handle delayed or asynchronous processing. config WQUEUE_NOTIFIER bool "Generic work notifier" default n depends on SCHED_WORKQUEUE ---help--- Enable building of work queue notifier logic that will execute a worker function an event occurs. This is is a general purpose notifier, but was developed specifically to support poll() logic where the poll must wait for an resources to become available. config SCHED_HPWORK bool "High priority (kernel) worker thread" default n select SCHED_WORKQUEUE ---help--- Create a dedicated high-priority "worker" thread to handle delayed processing from interrupt handlers. This feature is required for some drivers but, if there are no complaints, can be safely disabled. The high priority worker thread also performs garbage collection -- completing any delayed memory deallocations from interrupt handlers. If the high-priority worker thread is disabled, then that clean up will be performed either by (1) the low-priority worker thread, if enabled, and if not (2) the IDLE thread instead (which runs at the lowest of priority and may not be appropriate if memory reclamation is of high priority) For other, less-critical asynchronous or delayed process, the low-priority worker thread is recommended. if SCHED_HPWORK config SCHED_HPNTHREADS int "Number of high-priority worker threads" default 1 ---help--- This options selects multiple, high-priority threads. This is essentially a "thread pool" that provides multi-threaded servicing of the high-priority work queue. This breaks the serialization of the "queue" (hence, it is no longer a queue at all). CAUTION: Some drivers may use the work queue to serialize operations. They may also use the high-priority work queue if it is available. If there are multiple high-priority worker threads, then this can result in the loss of that serialization. There may be concurrent driver operations running on different HP threads and this could lead to a failure. You may need to visit the use of the HP work queue on your configuration is you select CONFIG_SCHED_HPNTHREADS > 1 config SCHED_HPWORKPRIORITY int "High priority worker thread priority" default 224 ---help--- The execution priority of the higher priority worker thread. The higher priority worker thread is intended to serve as the "bottom" half for device drivers. As a consequence it must run at a very high, fixed priority. Typically, it should be the highest priority thread in your system. Default: 224 For lower priority, application oriented worker thread support, please consider enabling the lower priority work queue. The lower priority work queue runs at a lower priority, of course, but has the added advantage that it supports "priority inheritance" (if PRIORITY_INHERITANCE is also selected): The priority of the lower priority worker thread can then be adjusted to match the highest priority client. config SCHED_HPWORKSTACKSIZE int "High priority worker thread stack size" default DEFAULT_TASK_STACKSIZE ---help--- The stack size allocated for the worker thread. Default: 2K. endif # SCHED_HPWORK config SCHED_LPWORK bool "Low priority (kernel) worker thread" default n select SCHED_WORKQUEUE ---help--- If SCHED_LPWORK is defined then a lower-priority work queue will be created. This lower priority work queue is better suited for more extended, application oriented processing (such as file system clean-up operations or asynchronous I/O) if SCHED_LPWORK config SCHED_LPNTHREADS int "Number of low-priority worker threads" default 1 if !FS_AIO default 4 if FS_AIO ---help--- This options selects multiple, low-priority threads. This is essentially a "thread pool" that provides multi-threaded servicing of the low-priority work queue. This breaks the serialization of the "queue" (hence, it is no longer a queue at all). This options is required to support, for example, I/O operations that stall waiting for input. If there is only a single thread, then the entire low-priority queue processing stalls in such cases. Such behavior is necessary to support asynchronous I/O, AIO (for example). CAUTION: Some drivers may use the work queue to serialize operations. They may also use the low-priority work queue if it is available. If there are multiple low-priority worker threads, then this can result in the loss of that serialization. There may be concurrent driver operations running on different LP threads and this could lead to a failure. You may need to visit the use of the LP work queue on your configuration is you select CONFIG_SCHED_LPNTHREADS > 1 config SCHED_LPWORKPRIORITY int "Low priority worker thread priority" default 100 ---help--- The minimum execution priority of the lower priority worker thread. The lower priority worker thread is intended support application- oriented functions. The lower priority work queue runs at a lower priority, of course, but has the added advantage that it supports "priority inheritance" (if PRIORITY_INHERITANCE is also selected): The priority of the lower priority worker thread can then be adjusted to match the highest priority client. Default: 100 NOTE: This priority inheritance feature is not automatic. The lower priority worker thread will always a fixed priority unless you implement logic that calls lpwork_boostpriority() to raise the priority of the lower priority worker thread (typically called before scheduling the work) and then call the matching lpwork_restorepriority() when the work is completed (typically called within the work handler at the completion of the work). Currently, only the NuttX asynchronous I/O logic uses this dynamic prioritization feature. The higher priority worker thread, on the other hand, is intended to serve as the "bottom" half for device drivers. As a consequence it must run at a very high, fixed priority. Typically, it should be the highest priority thread in your system. config SCHED_LPWORKPRIOMAX int "Low priority worker thread maximum priority" default 176 depends on PRIORITY_INHERITANCE ---help--- The maximum execution priority of the lower priority worker thread. The lower priority worker thread is intended support application- oriented functions. The lower priority work queue runs at a lower priority, of course, but has the added advantage that it supports "priority inheritance" (if PRIORITY_INHERITANCE is also selected): The priority of the lower priority worker thread can then be adjusted to match the highest priority client. The higher priority worker thread, on the other hand, is intended to serve as the "bottom" half for device drivers. As a consequence it must run at a very high, fixed priority. Typically, it should be the highest priority thread in your system. This value provides an upper limit on the priority of the lower priority worker thread. This would be necessary, for example, if the higher priority worker thread were to defer work to the lower priority thread. Clearly, in such a case, you would want to limit the maximum priority of the lower priority work thread. Default: 176 config SCHED_LPWORKSTACKSIZE int "Low priority worker thread stack size" default DEFAULT_TASK_STACKSIZE ---help--- The stack size allocated for the lower priority worker thread. Default: 2K. endif # SCHED_LPWORK endmenu # Work Queue Support menu "Stack and heap information" config DEFAULT_TASK_STACKSIZE int "The default stack size for tasks" default 2048 ---help--- The default stack size for tasks. config IDLETHREAD_STACKSIZE int "Idle thread stack size" default 1024 ---help--- The size of the initial stack used by the IDLE thread. The IDLE thread is the thread that (1) performs the initial boot of the system up to the point where start-up application is spawned, and (2) there after is the IDLE thread that executes only when there is no other thread ready to run. config PTHREAD_STACK_MIN int "Minimum pthread stack size" default 256 ---help--- Minimum pthread stack size config PTHREAD_STACK_DEFAULT int "Default pthread stack size" default DEFAULT_TASK_STACKSIZE ---help--- Default pthread stack size endmenu # Stack and heap information config SCHED_BACKTRACE bool "Stack BackTrace" default "n" ---help--- This option enables stack backtrace support in the NuttX using the information automatically generated by the compiler or architecture specific approach when ARCH_HAVE_BACKTRACE is selected