nuttx/sched/Kconfig

#
# 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 EXPERIMENTAL && 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
	---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() 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) <arch>_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/<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) <arch>_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/<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