2012-04-06 17:49:35 +02:00
|
|
|
|
#
|
|
|
|
|
# For a description of the syntax of this configuration file,
|
2015-06-28 16:08:57 +02:00
|
|
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
2012-04-06 17:49:35 +02:00
|
|
|
|
#
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
menuconfig DISABLE_OS_API
|
|
|
|
|
bool "Disable NuttX interfaces"
|
|
|
|
|
default y
|
2013-02-15 15:37:37 +01:00
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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.
|
2013-02-15 15:37:37 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
if DISABLE_OS_API
|
2013-02-15 15:37:37 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config DISABLE_POSIX_TIMERS
|
|
|
|
|
bool "Disable POSIX timers"
|
2022-02-28 15:23:37 +01:00
|
|
|
|
default DEFAULT_SMALL
|
2019-11-16 15:23:09 +01:00
|
|
|
|
---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.
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
config DISABLE_PTHREAD
|
|
|
|
|
bool "Disable pthread support"
|
2022-02-28 15:23:37 +01:00
|
|
|
|
default DEFAULT_SMALL
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
config DISABLE_MQUEUE
|
|
|
|
|
bool "Disable POSIX message queue support"
|
2022-02-28 15:23:37 +01:00
|
|
|
|
default DEFAULT_SMALL
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
2022-10-19 16:28:43 +02:00
|
|
|
|
config DISABLE_MQUEUE_SYSV
|
|
|
|
|
bool "Disable System V message queue support"
|
|
|
|
|
default DISABLE_MQUEUE
|
|
|
|
|
---help---
|
|
|
|
|
Disable System V message queue support
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config DISABLE_ENVIRON
|
|
|
|
|
bool "Disable environment variable support"
|
2022-02-28 15:23:37 +01:00
|
|
|
|
default DEFAULT_SMALL
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
endif # DISABLE_OS_API
|
|
|
|
|
|
|
|
|
|
menu "Clocks and Timers"
|
2013-02-15 15:37:37 +01:00
|
|
|
|
|
2014-08-07 19:39:16 +02:00
|
|
|
|
config ARCH_HAVE_TICKLESS
|
|
|
|
|
bool
|
|
|
|
|
|
2014-08-07 02:25:42 +02:00
|
|
|
|
config SCHED_TICKLESS
|
|
|
|
|
bool "Support tick-less OS"
|
|
|
|
|
default n
|
2014-08-08 03:11:22 +02:00
|
|
|
|
depends on ARCH_HAVE_TICKLESS
|
2014-08-07 02:25:42 +02:00
|
|
|
|
---help---
|
2014-08-12 15:28:41 +02:00
|
|
|
|
By default, system time is driven by a periodic timer interrupt. An
|
2014-08-07 02:25:42 +02:00
|
|
|
|
alternative configurations is a tick-less configuration in which
|
2021-12-20 15:49:48 +01:00
|
|
|
|
there is no periodic timer interrupt. Instead an interval timer is
|
2014-08-07 02:25:42 +02:00
|
|
|
|
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
|
2014-08-08 03:11:22 +02:00
|
|
|
|
additional platform specific interfaces that must be provided as
|
2021-12-20 15:49:48 +01:00
|
|
|
|
defined in include/nuttx/arch.h
|
2014-08-07 02:25:42 +02:00
|
|
|
|
|
2014-08-12 15:28:41 +02:00
|
|
|
|
if SCHED_TICKLESS
|
2015-02-03 13:25:19 +01:00
|
|
|
|
|
2022-09-26 04:02:52 +02:00
|
|
|
|
config SCHED_TICKLESS_TICK_ARGUMENT
|
|
|
|
|
bool "Scheduler use tick argument"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Enables use of tick argument in scheduler. If enabled, then the
|
|
|
|
|
board-specific logic must provide the following functions:
|
|
|
|
|
|
|
|
|
|
int up_timer_gettick(FAR clock_t *ticks);
|
|
|
|
|
|
|
|
|
|
If SCHED_TICKLESS_ALARM is enabled, then these additional interfaces are
|
|
|
|
|
expected:
|
|
|
|
|
|
|
|
|
|
int up_alarm_tick_cancel(FAR clock_t *ticks);
|
|
|
|
|
int up_alarm_tick_start(clock_t ticks);
|
|
|
|
|
|
|
|
|
|
Otherwise, these additional interfaces are expected:
|
|
|
|
|
|
|
|
|
|
int up_timer_tick_cancel(FAR clock_t *ticks);
|
|
|
|
|
int up_timer_tick_start(FAR clock_t ticks);
|
|
|
|
|
|
2014-08-12 18:00:32 +02:00
|
|
|
|
config SCHED_TICKLESS_ALARM
|
2014-08-12 15:28:41 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2015-02-03 13:25:19 +01:00
|
|
|
|
config SCHED_TICKLESS_LIMIT_MAX_SLEEP
|
|
|
|
|
bool "Max sleep period (in microseconds)"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
2015-02-03 14:18:17 +01:00
|
|
|
|
Enables use of the g_oneshot_maxticks variable. This variable is
|
2015-02-03 13:25:19 +01:00
|
|
|
|
initialized by platform-specific logic at runtime to the maximum
|
2015-02-03 14:18:17 +01:00
|
|
|
|
delay that the timer can wait (in configured clock ticks). The
|
|
|
|
|
RTOS tickless logic will then limit all requested delays to this
|
|
|
|
|
value.
|
2015-02-03 13:25:19 +01:00
|
|
|
|
|
2014-08-12 15:28:41 +02:00
|
|
|
|
endif
|
|
|
|
|
|
2014-08-07 21:42:47 +02:00
|
|
|
|
config USEC_PER_TICK
|
2014-08-07 22:14:09 +02:00
|
|
|
|
int "System timer tick period (microseconds)"
|
2014-08-07 21:42:47 +02:00
|
|
|
|
default 10000 if !SCHED_TICKLESS
|
|
|
|
|
default 100 if SCHED_TICKLESS
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2014-08-07 21:42:47 +02:00
|
|
|
|
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
|
2017-05-11 21:35:56 +02:00
|
|
|
|
to inform of NuttX the interval that the processor hardware is
|
2014-08-07 21:42:47 +02:00
|
|
|
|
providing system timer interrupts to the OS.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2014-08-07 02:25:42 +02:00
|
|
|
|
If SCHED_TICKLESS is selected, then there are no system timer
|
2014-08-07 21:42:47 +02:00
|
|
|
|
interrupts. In this case, USEC_PER_TICK does not control any timer
|
2014-08-07 02:25:42 +02:00
|
|
|
|
rates. Rather, it only determines the resolution of time reported
|
2020-05-04 16:15:10 +02:00
|
|
|
|
by clock_systime_ticks() and the resolution of times that can be set for
|
2014-08-07 21:42:47 +02:00
|
|
|
|
certain delays including watchdog timers and delayed work. In this
|
2014-08-07 22:14:09 +02:00
|
|
|
|
case there is a trade-off: It is better to have the USEC_PER_TICK as
|
2017-05-11 21:35:56 +02:00
|
|
|
|
low as possible for higher timing resolution. However, the time
|
2014-08-07 21:42:47 +02:00
|
|
|
|
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
|
2014-08-07 22:14:09 +02:00
|
|
|
|
of values that delays that can be represented. So the trade-off is
|
2014-08-07 21:42:47 +02:00
|
|
|
|
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.
|
2014-08-07 02:25:42 +02:00
|
|
|
|
|
2014-08-08 02:00:38 +02:00
|
|
|
|
This value should never be less than the underlying resolution of
|
|
|
|
|
the timer. Error may ensue.
|
|
|
|
|
|
2014-08-07 02:25:42 +02:00
|
|
|
|
if !SCHED_TICKLESS
|
|
|
|
|
|
2014-04-30 22:46:26 +02:00
|
|
|
|
config SYSTEMTICK_EXTCLK
|
|
|
|
|
bool "Use external clock"
|
|
|
|
|
default n
|
2014-04-30 23:32:06 +02:00
|
|
|
|
depends on ARCH_HAVE_EXTCLK
|
2014-04-30 22:46:26 +02:00
|
|
|
|
---help---
|
|
|
|
|
Use external clock for system tick. When enabled, the platform-specific
|
2014-05-05 22:38:29 +02:00
|
|
|
|
logic must start its own timer interrupt to make periodic calls to the
|
2019-03-21 02:27:40 +01:00
|
|
|
|
nxsched_process_timer() or the functions called within. The purpose is
|
2014-05-05 22:38:29 +02:00
|
|
|
|
to move the scheduling off the processor clock to allow entering low
|
|
|
|
|
power states that would disable that clock.
|
2014-04-30 22:46:26 +02:00
|
|
|
|
|
2019-01-30 14:22:44 +01:00
|
|
|
|
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).
|
|
|
|
|
|
2014-08-07 02:25:42 +02:00
|
|
|
|
endif # !SCHED_TICKLESS
|
|
|
|
|
|
2013-12-14 22:25:23 +01:00
|
|
|
|
config SYSTEM_TIME64
|
|
|
|
|
bool "64-bit system clock"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
The system timer is incremented at the rate determined by
|
2014-08-07 21:42:47 +02:00
|
|
|
|
USEC_PER_TICK, typically at 100Hz. The count at any given time is
|
2013-12-14 22:25:23 +01:00
|
|
|
|
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
|
2016-01-21 18:54:26 +01:00
|
|
|
|
497 days which is probably a sufficient range for "uptime".
|
2013-12-14 22:25:23 +01:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2016-07-11 00:14:25 +02:00
|
|
|
|
config ARCH_HAVE_TIMEKEEPING
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2016-07-11 14:54:02 +02:00
|
|
|
|
config CLOCK_TIMEKEEPING
|
2016-07-11 00:14:25 +02:00
|
|
|
|
bool "Support timekeeping algorithms"
|
|
|
|
|
default n
|
2022-09-16 07:08:21 +02:00
|
|
|
|
depends on ARCH_HAVE_TIMEKEEPING
|
2016-07-11 00:14:25 +02:00
|
|
|
|
---help---
|
2016-07-11 14:54:02 +02:00
|
|
|
|
CLOCK_TIMEKEEPING enables experimental time management algorithms.
|
2016-07-11 00:14:25 +02:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config JULIAN_TIME
|
|
|
|
|
bool "Enables Julian time conversions"
|
2014-02-22 22:20:12 +01:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
Enables Julian time conversions
|
2014-02-22 22:20:12 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config START_YEAR
|
|
|
|
|
int "Start year"
|
2018-01-03 15:32:57 +01:00
|
|
|
|
default 2018
|
2016-10-28 02:04:14 +02:00
|
|
|
|
range 1970 2106
|
|
|
|
|
---help---
|
|
|
|
|
NuttX uses an unsigned 32-bit integer for time_t which provides a
|
|
|
|
|
range from 1970 to 2106.
|
2014-02-22 22:20:12 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config START_MONTH
|
|
|
|
|
int "Start month"
|
|
|
|
|
default 1
|
2016-10-28 02:04:14 +02:00
|
|
|
|
range 1 12
|
2014-02-27 21:13:53 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config START_DAY
|
|
|
|
|
int "Start day"
|
|
|
|
|
default 1
|
2016-10-28 02:04:14 +02:00
|
|
|
|
range 1 31
|
2014-02-27 21:13:53 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config PREALLOC_TIMERS
|
|
|
|
|
int "Number of pre-allocated POSIX timers"
|
2021-11-07 16:00:01 +01:00
|
|
|
|
default 4 if DEFAULT_SMALL
|
|
|
|
|
default 8 if !DEFAULT_SMALL
|
2022-09-16 07:11:00 +02:00
|
|
|
|
depends on !DISABLE_POSIX_TIMERS
|
2014-02-22 22:20:12 +01:00
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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.
|
2014-02-22 22:20:12 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endmenu # Clocks and Timers
|
2014-02-22 22:20:12 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
menu "Tasks and Scheduling"
|
|
|
|
|
|
2016-02-10 17:27:48 +01:00
|
|
|
|
config SPINLOCK
|
|
|
|
|
bool "Support Spinlocks"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
2019-09-20 02:19:18 +02:00
|
|
|
|
Enables support for spinlocks. Spinlocks are used primarily for
|
2019-03-05 20:08:57 +01:00
|
|
|
|
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.
|
2016-02-10 17:27:48 +01:00
|
|
|
|
|
2018-08-24 23:10:23 +02:00
|
|
|
|
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"
|
2021-11-07 16:00:01 +01:00
|
|
|
|
default 4 if DEFAULT_SMALL
|
|
|
|
|
default 8 if !DEFAULT_SMALL
|
2018-08-24 23:10:23 +02:00
|
|
|
|
---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
|
|
|
|
|
|
2018-11-25 18:50:15 +01:00
|
|
|
|
config IRQCOUNT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2016-02-10 17:27:48 +01:00
|
|
|
|
config SMP
|
|
|
|
|
bool "Symmetric Multi-Processing (SMP)"
|
|
|
|
|
default n
|
2016-10-29 22:56:07 +02:00
|
|
|
|
depends on ARCH_HAVE_MULTICPU
|
2020-12-30 07:24:51 +01:00
|
|
|
|
depends on ARCH_HAVE_TESTSET
|
2021-06-28 10:57:19 +02:00
|
|
|
|
depends on ARCH_INTERRUPTSTACK != 0
|
2016-02-10 17:27:48 +01:00
|
|
|
|
select SPINLOCK
|
2018-11-25 18:50:15 +01:00
|
|
|
|
select SCHED_RESUMESCHEDULER
|
|
|
|
|
select IRQCOUNT
|
2016-02-10 17:27:48 +01:00
|
|
|
|
---help---
|
2016-02-22 15:28:33 +01:00
|
|
|
|
Enables support for Symmetric Multi-Processing (SMP) on a multi-CPU
|
2016-02-10 17:27:48 +01:00
|
|
|
|
platform.
|
|
|
|
|
|
2021-06-28 10:57:19 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2016-02-10 17:27:48 +01:00
|
|
|
|
if SMP
|
|
|
|
|
|
|
|
|
|
config SMP_NCPUS
|
|
|
|
|
int "Number of CPUs"
|
|
|
|
|
default 4
|
2021-08-20 03:05:32 +02:00
|
|
|
|
range 1 32
|
2016-02-10 17:27:48 +01:00
|
|
|
|
---help---
|
2016-02-22 15:28:33 +01:00
|
|
|
|
This value identifies the number of CPUs supported by the processor
|
2016-02-10 17:27:48 +01:00
|
|
|
|
that will be used for SMP.
|
|
|
|
|
|
2018-07-09 02:24:45 +02:00
|
|
|
|
If CONFIG_DEBUG_FEATURES is enabled, then the value one is permitted
|
2017-03-22 13:29:38 +01:00
|
|
|
|
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.
|
|
|
|
|
|
2016-02-10 17:27:48 +01:00
|
|
|
|
endif # SMP
|
|
|
|
|
|
2014-08-30 21:27:23 +02:00
|
|
|
|
choice
|
|
|
|
|
prompt "Initialization Task"
|
2021-12-20 05:21:47 +01:00
|
|
|
|
default INIT_ENTRY if !BUILD_KERNEL
|
|
|
|
|
default INIT_FILE if !BINFMT_DISABLE
|
2020-04-29 16:52:26 +02:00
|
|
|
|
default INIT_NONE if BINFMT_DISABLE
|
2014-08-30 21:27:23 +02:00
|
|
|
|
|
|
|
|
|
config INIT_NONE
|
2014-09-11 15:18:33 +02:00
|
|
|
|
bool "None"
|
2014-08-30 21:27:23 +02:00
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
config INIT_ENTRY
|
|
|
|
|
bool "Via application entry"
|
2014-08-30 21:27:23 +02:00
|
|
|
|
depends on !BUILD_KERNEL
|
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
config INIT_FILE
|
2014-08-30 21:27:23 +02:00
|
|
|
|
bool "Via executable file"
|
|
|
|
|
depends on !BINFMT_DISABLE
|
|
|
|
|
|
|
|
|
|
endchoice # Initialization task
|
|
|
|
|
|
2020-08-16 20:05:58 +02:00
|
|
|
|
config INIT_ARGS
|
|
|
|
|
string "Application argument list"
|
|
|
|
|
depends on !INIT_NONE
|
|
|
|
|
---help---
|
|
|
|
|
The argument list for user applications. e.g.:
|
|
|
|
|
"\"arg1\",\"arg2\",\"arg3\""
|
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
config INIT_STACKSIZE
|
2020-08-16 20:05:58 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
config INIT_PRIORITY
|
2018-12-20 17:49:10 +01:00
|
|
|
|
int "init thread priority"
|
|
|
|
|
default 100
|
|
|
|
|
---help---
|
|
|
|
|
The priority of the user initialization thread.
|
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
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".
|
2014-08-30 21:27:23 +02:00
|
|
|
|
|
2021-12-20 05:30:57 +01:00
|
|
|
|
config INIT_ENTRYNAME
|
|
|
|
|
string "Application entry name"
|
|
|
|
|
default INIT_ENTRYPOINT
|
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
endif # INIT_ENTRY
|
2014-08-30 21:27:23 +02:00
|
|
|
|
|
2021-12-20 05:21:47 +01:00
|
|
|
|
if INIT_FILE
|
|
|
|
|
|
|
|
|
|
config INIT_FILEPATH
|
2014-08-30 21:27:23 +02:00
|
|
|
|
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
|
2021-12-20 05:21:47 +01:00
|
|
|
|
name. If not defined, INIT_ENTRYPOINT defaults to "main".
|
2014-08-30 21:27:23 +02:00
|
|
|
|
|
|
|
|
|
config INIT_SYMTAB
|
|
|
|
|
string "Symbol table"
|
2018-08-22 14:21:20 +02:00
|
|
|
|
default "NULL" if !EXECFUNCS_HAVE_SYMTAB
|
|
|
|
|
default EXECFUNCS_SYMTAB_ARRAY if EXECFUNCS_HAVE_SYMTAB
|
2020-04-29 16:52:26 +02:00
|
|
|
|
depends on BUILD_FLAT
|
2014-08-30 21:27:23 +02:00
|
|
|
|
---help---
|
2020-02-23 09:50:23 +01:00
|
|
|
|
The name of other global array that holds the exported symbol table.
|
2014-08-30 21:27:23 +02:00
|
|
|
|
The special string "NULL" may be provided if there is no symbol
|
|
|
|
|
table. Quotation marks will be stripped when config.h is generated.
|
|
|
|
|
|
2014-08-31 15:15:46 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2014-08-30 21:27:23 +02:00
|
|
|
|
config INIT_NEXPORTS
|
|
|
|
|
string "Symbol table size"
|
2018-08-22 14:21:20 +02:00
|
|
|
|
default "0" if !EXECFUNCS_HAVE_SYMTAB
|
|
|
|
|
default EXECFUNCS_NSYMBOLS_VAR if EXECFUNCS_HAVE_SYMTAB
|
2020-04-29 16:52:26 +02:00
|
|
|
|
depends on BUILD_FLAT
|
2014-08-30 21:27:23 +02:00
|
|
|
|
---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.
|
|
|
|
|
|
2014-08-31 15:15:46 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2018-08-23 19:08:22 +02:00
|
|
|
|
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
|
2021-12-20 05:21:47 +01:00
|
|
|
|
endif # INIT_FILE
|
2014-08-30 21:27:23 +02:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config RR_INTERVAL
|
|
|
|
|
int "Round robin timeslice (MSEC)"
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
The round robin timeslice will be set this number of milliseconds;
|
2020-01-20 13:32:36 +01:00
|
|
|
|
Round robin scheduling (SCHED_RR) is enabled by setting this
|
2015-07-23 18:33:30 +02:00
|
|
|
|
interval to a positive, non-zero value.
|
|
|
|
|
|
|
|
|
|
config SCHED_SPORADIC
|
|
|
|
|
bool "Support sporadic scheduling"
|
|
|
|
|
default n
|
2018-11-25 18:50:15 +01:00
|
|
|
|
select SCHED_SUSPENDSCHEDULER
|
|
|
|
|
select SCHED_RESUMESCHEDULER
|
2015-07-23 18:33:30 +02:00
|
|
|
|
---help---
|
2015-07-25 20:50:53 +02:00
|
|
|
|
Build in additional logic to support sporadic scheduling
|
|
|
|
|
(SCHED_SPORADIC).
|
|
|
|
|
|
2015-07-27 16:37:25 +02:00
|
|
|
|
if SCHED_SPORADIC
|
|
|
|
|
|
2015-07-25 20:50:53 +02:00
|
|
|
|
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.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2015-07-27 16:37:25 +02:00
|
|
|
|
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:
|
|
|
|
|
|
2016-03-17 16:49:43 +01:00
|
|
|
|
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);
|
2015-07-27 16:37:25 +02:00
|
|
|
|
|
|
|
|
|
endif # SCHED_SPORADIC
|
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config TASK_NAME_SIZE
|
2012-04-11 19:13:04 +02:00
|
|
|
|
int "Maximum task name size"
|
2014-12-17 19:24:02 +01:00
|
|
|
|
default 31
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2019-06-13 13:52:40 +02:00
|
|
|
|
Specifies the maximum size of a task name to save in the TCB.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
Useful if scheduler instrumentation is selected. Set to zero to
|
2014-12-17 19:24:02 +01:00
|
|
|
|
disable. Excludes the NUL terminator; the actual allocated size
|
2019-06-13 13:52:40 +02:00
|
|
|
|
will be TASK_NAME_SIZE + 1. The default of 31 then results in
|
|
|
|
|
a align-able 32-byte allocation.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2013-01-12 20:58:45 +01:00
|
|
|
|
config SCHED_HAVE_PARENT
|
2013-01-17 15:43:55 +01:00
|
|
|
|
bool "Support parent/child task relationships"
|
2013-01-12 20:58:45 +01:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2013-01-23 23:23:46 +01:00
|
|
|
|
Remember the ID of the parent task when a new child task is
|
2013-01-13 19:53:00 +01:00
|
|
|
|
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:
|
2013-01-12 20:58:45 +01:00
|
|
|
|
disabled.
|
|
|
|
|
|
2013-01-23 23:23:46 +01:00
|
|
|
|
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
|
2020-02-23 09:50:23 +01:00
|
|
|
|
selected if you require knowledge of a child process's exit status.
|
2013-01-23 23:23:46 +01:00
|
|
|
|
Without this setting, wait(), waitpid() or waitid() may fail. For
|
|
|
|
|
example, if you do:
|
|
|
|
|
|
2013-04-22 17:10:58 +02:00
|
|
|
|
1) Start child task
|
|
|
|
|
2) Wait for exit status (using wait(), waitpid(), or waitid()).
|
2013-01-23 23:23:46 +01:00
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
if SCHED_CHILD_STATUS
|
|
|
|
|
|
2013-01-23 23:23:46 +01:00
|
|
|
|
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
|
2021-06-15 10:45:40 +02:00
|
|
|
|
of child status structures that will be pre-allocated.
|
2013-01-23 23:23:46 +01:00
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
2013-01-25 00:18:32 +01:00
|
|
|
|
config DEBUG_CHILDSTATUS
|
|
|
|
|
bool "Enable Child Status Debug Output"
|
|
|
|
|
default n
|
2016-06-11 22:14:08 +02:00
|
|
|
|
depends on SCHED_CHILD_STATUS && DEBUG_FEATURES
|
2013-01-25 00:18:32 +01:00
|
|
|
|
---help---
|
|
|
|
|
Very detailed... I am sure that you do not want this.
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endif # SCHED_CHILD_STATUS
|
|
|
|
|
|
|
|
|
|
config SCHED_WAITPID
|
|
|
|
|
bool "Enable waitpid() API"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2022-10-28 05:42:13 +02:00
|
|
|
|
config SCHED_DUMP_LEAK
|
|
|
|
|
bool "Enable catch task memory leak"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
When this option is enabled, the task's outstanding memory allocations
|
|
|
|
|
are printed using syslog. This helps catch any memory allocated by the
|
|
|
|
|
task that remains unreleased when the task exits.
|
|
|
|
|
|
2019-08-06 22:13:43 +02:00
|
|
|
|
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
|
2020-02-23 09:50:23 +01:00
|
|
|
|
versions of these interfaces are available. When selected, these
|
2019-08-06 22:13:43 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2021-12-03 14:35:39 +01:00
|
|
|
|
config SCHED_THREAD_LOCAL
|
|
|
|
|
bool "Support __thread/thread_local keyword"
|
|
|
|
|
default n
|
|
|
|
|
depends on ARCH_HAVE_THREAD_LOCAL
|
|
|
|
|
---help---
|
2021-12-20 15:49:48 +01:00
|
|
|
|
This option enables architecture-specific TLS support (__thread/thread_local keyword)
|
2021-12-03 14:35:39 +01:00
|
|
|
|
Note: Toolchain must be compiled with '--enable-tls' enabled
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endmenu # Tasks and Scheduling
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
menu "Pthread Options"
|
2020-05-08 20:02:42 +02:00
|
|
|
|
depends on !DISABLE_PTHREAD
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2017-03-27 17:08:14 +02:00
|
|
|
|
config PTHREAD_MUTEX_TYPES
|
2012-04-11 19:13:04 +02:00
|
|
|
|
bool "Enable mutex types"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
Set to enable support for recursive and errorcheck mutexes. Enables
|
|
|
|
|
pthread_mutexattr_settype().
|
|
|
|
|
|
2017-03-27 01:37:28 +02:00
|
|
|
|
choice
|
|
|
|
|
prompt "pthread mutex robustness"
|
|
|
|
|
default PTHREAD_MUTEX_ROBUST if !DEFAULT_SMALL
|
2018-08-05 18:48:02 +02:00
|
|
|
|
default PTHREAD_MUTEX_UNSAFE if DEFAULT_SMALL
|
2017-03-27 01:37:28 +02:00
|
|
|
|
|
2017-03-27 18:49:41 +02:00
|
|
|
|
config PTHREAD_MUTEX_ROBUST
|
2017-03-27 01:37:28 +02:00
|
|
|
|
bool "Robust mutexes"
|
|
|
|
|
---help---
|
|
|
|
|
Support only the robust form of the NORMAL mutex.
|
|
|
|
|
|
2017-03-27 18:49:41 +02:00
|
|
|
|
config PTHREAD_MUTEX_UNSAFE
|
2017-03-27 01:37:28 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2017-03-27 18:49:41 +02:00
|
|
|
|
config PTHREAD_MUTEX_BOTH
|
2017-03-27 02:37:24 +02:00
|
|
|
|
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
|
|
|
|
|
|
2017-03-27 18:49:41 +02:00
|
|
|
|
config PTHREAD_MUTEX_DEFAULT_ROBUST
|
2017-03-27 02:37:24 +02:00
|
|
|
|
bool "Robust default"
|
|
|
|
|
---help---
|
|
|
|
|
The default is robust NORMAL mutexes (non-standard)
|
|
|
|
|
|
2017-03-27 18:49:41 +02:00
|
|
|
|
config PTHREAD_MUTEX_DEFAULT_UNSAFE
|
2017-03-27 02:37:24 +02:00
|
|
|
|
bool "Unsafe default"
|
|
|
|
|
---help---
|
|
|
|
|
The default is traditional unsafe NORMAL mutexes (standard)
|
|
|
|
|
|
|
|
|
|
endchoice # Default NORMAL mutex robustness
|
2017-03-27 01:37:28 +02:00
|
|
|
|
|
2022-01-06 11:02:13 +01:00
|
|
|
|
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
|
|
|
|
|
|
2016-12-08 16:27:13 +01:00
|
|
|
|
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
|
2016-12-08 21:33:02 +01:00
|
|
|
|
pthread task control block by about n * CONFIG_PTHREAD_CLEANUP_STACKSIZE
|
2022-01-10 15:51:17 +01:00
|
|
|
|
where n is the size of a pointer, 2 * sizeof(uintptr_t), this would be
|
2016-12-08 21:33:02 +01:00
|
|
|
|
8 for a CPU with 32-bit addressing and 4 for a CPU with 16-bit
|
|
|
|
|
addressing.
|
2016-12-08 16:27:13 +01:00
|
|
|
|
|
2016-12-09 14:23:00 +01:00
|
|
|
|
config CANCELLATION_POINTS
|
|
|
|
|
bool "Cancellation points"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Enable POSIX cancellation points for pthread_cancel(). If selected,
|
2021-12-20 15:49:48 +01:00
|
|
|
|
cancellation points will also used with the task_delete() API even if
|
2016-12-09 14:23:00 +01:00
|
|
|
|
pthreads are not enabled.
|
|
|
|
|
|
2017-04-10 16:11:16 +02:00
|
|
|
|
endmenu # Pthread Options
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
menu "Performance Monitoring"
|
|
|
|
|
|
2018-11-25 18:50:15 +01:00
|
|
|
|
config SCHED_SUSPENDSCHEDULER
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config SCHED_RESUMESCHEDULER
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2018-01-13 00:41:09 +01:00
|
|
|
|
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".
|
|
|
|
|
|
2018-11-24 17:32:45 +01:00
|
|
|
|
config SCHED_CRITMONITOR
|
|
|
|
|
bool "Enable Critical Section monitoring"
|
|
|
|
|
default n
|
|
|
|
|
depends on FS_PROCFS
|
2018-11-25 18:50:15 +01:00
|
|
|
|
select SCHED_SUSPENDSCHEDULER
|
|
|
|
|
select SCHED_RESUMESCHEDULER
|
|
|
|
|
select IRQCOUNT
|
2018-11-24 17:32:45 +01:00
|
|
|
|
---help---
|
|
|
|
|
Enables logic that monitors the duration of time that a thread keeps
|
|
|
|
|
interrupts or pre-emption disabled. These global locks can have
|
2020-12-21 23:02:03 +01:00
|
|
|
|
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
|
2018-11-24 17:32:45 +01:00
|
|
|
|
interrupt handler until the task that responds to the event can run.
|
|
|
|
|
|
2021-04-29 13:41:27 +02:00
|
|
|
|
if SCHED_CRITMONITOR
|
|
|
|
|
|
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_THREAD
|
|
|
|
|
int "THREAD max execution time"
|
|
|
|
|
default 0
|
|
|
|
|
---help---
|
|
|
|
|
Thread execution time should be smaller than
|
2021-12-20 15:49:48 +01:00
|
|
|
|
SCHED_CRITMONITOR_MAXTIME_THREAD, or system will give a warning.
|
|
|
|
|
For debugging system latency, 0 means disabled.
|
2021-04-29 13:41:27 +02:00
|
|
|
|
|
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_WQUEUE
|
|
|
|
|
int "WORK queue max execution time"
|
|
|
|
|
default SCHED_CRITMONITOR_MAXTIME_THREAD
|
|
|
|
|
---help---
|
|
|
|
|
Worker execution time should be smaller than
|
2021-12-20 15:49:48 +01:00
|
|
|
|
SCHED_CRITMONITOR_MAXTIME_WQUEUE, or system will give a warning.
|
|
|
|
|
For debugging system latency, 0 means disabled.
|
2021-04-29 13:41:27 +02:00
|
|
|
|
|
|
|
|
|
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
|
2021-12-20 15:49:48 +01:00
|
|
|
|
SCHED_CRITMONITOR_MAXTIME_PREEMPTION, or system will give a warning.
|
|
|
|
|
For debugging system latency, 0 means disabled.
|
2021-04-29 13:41:27 +02:00
|
|
|
|
|
|
|
|
|
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
|
2021-12-20 15:49:48 +01:00
|
|
|
|
SCHED_CRITMONITOR_MAXTIME_CSECTION, or system will give a warning.
|
|
|
|
|
For debugging system latency, 0 means disabled.
|
2021-04-29 13:41:27 +02:00
|
|
|
|
|
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_IRQ
|
|
|
|
|
int "IRQ max execution time"
|
|
|
|
|
default SCHED_CRITMONITOR_MAXTIME_CSECTION
|
|
|
|
|
---help---
|
|
|
|
|
IRQ handler execution time should be smaller than
|
2021-12-20 15:49:48 +01:00
|
|
|
|
SCHED_CRITMONITOR_MAXTIME_IRQ, or system will give a warning.
|
|
|
|
|
For debugging system latency, 0 means disabled.
|
2021-04-29 13:41:27 +02:00
|
|
|
|
|
|
|
|
|
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
|
2021-12-20 15:49:48 +01:00
|
|
|
|
SCHED_CRITMONITOR_MAXTIME_WDOG, or system will give a warning.
|
|
|
|
|
For debugging system latency, 0 means disabled.
|
2021-04-29 13:41:27 +02:00
|
|
|
|
|
|
|
|
|
endif # SCHED_CRITMONITOR
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config SCHED_CPULOAD
|
|
|
|
|
bool "Enable CPU load monitoring"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default n
|
2014-08-07 19:39:16 +02:00
|
|
|
|
select SCHED_CPULOAD_EXTCLK if SCHED_TICKLESS
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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,
|
2020-12-21 23:02:03 +01:00
|
|
|
|
it can very accurately determine the percentage of the time that the
|
2014-03-31 19:32:22 +02:00
|
|
|
|
CPU is IDLE.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2020-12-21 23:02:03 +01:00
|
|
|
|
The statistics collected in this could be used, for example, in the
|
2014-03-31 19:32:22 +02:00
|
|
|
|
PROCFS file system to provide CPU load measurements when read.
|
|
|
|
|
|
2016-01-13 14:44:44 +01:00
|
|
|
|
Note that in tickless mode of operation (SCHED_TICKLESS) there is
|
|
|
|
|
no system timer interrupt and CPU load measurements will not be
|
2020-12-21 23:02:03 +01:00
|
|
|
|
possible unless you provide an alternative clock to drive the
|
2016-01-13 14:44:44 +01:00
|
|
|
|
sampling and select SCHED_CPULOAD_EXTCLK.
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
if SCHED_CPULOAD
|
|
|
|
|
|
|
|
|
|
config SCHED_CPULOAD_EXTCLK
|
|
|
|
|
bool "Use external clock"
|
|
|
|
|
default n
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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.
|
2012-04-07 16:50:57 +02:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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
|
2022-08-16 20:15:45 +02:00
|
|
|
|
nxsched_process_cpuload_ticks() at each timer expiration with interrupts
|
2014-03-31 19:32:22 +02:00
|
|
|
|
disabled.
|
|
|
|
|
|
2016-08-20 20:47:07 +02:00
|
|
|
|
if SCHED_CPULOAD_EXTCLK
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
config SCHED_CPULOAD_TICKSPERSEC
|
|
|
|
|
int "External clock rate"
|
|
|
|
|
default 100
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
If an external clock is used to drive the sampling for the CPU load
|
|
|
|
|
calculations, then this value must be provided. This value provides
|
2017-01-22 17:17:51 +01:00
|
|
|
|
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.
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
2018-08-24 18:10:57 +02:00
|
|
|
|
choice
|
|
|
|
|
prompt "Select CPU load timer"
|
|
|
|
|
default CPULOAD_ONESHOT
|
|
|
|
|
|
2016-08-20 20:47:07 +02:00
|
|
|
|
config CPULOAD_ONESHOT
|
|
|
|
|
bool "Use Oneshot timer"
|
|
|
|
|
---help---
|
2016-08-20 21:23:41 +02:00
|
|
|
|
Use an MCU-specific oneshot timer as the external clock. The
|
2016-08-20 20:47:07 +02:00
|
|
|
|
oneshot timer must be configured by board specific logic which must
|
|
|
|
|
then call:
|
|
|
|
|
|
2020-05-10 15:13:21 +02:00
|
|
|
|
void nxsched_oneshot_extclk(FAR struct oneshot_lowerhalf_s *lower);
|
2016-08-20 20:47:07 +02:00
|
|
|
|
|
|
|
|
|
To start the CPU load measurement. See include/nuttx/clock.h
|
|
|
|
|
|
2017-01-22 17:17:51 +01:00
|
|
|
|
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
|
2018-07-09 02:24:45 +02:00
|
|
|
|
the underly frequency driving the oneshot timer must be
|
2017-01-22 17:17:51 +01:00
|
|
|
|
significantly faster than CONFIG_SCHED_CPULOAD_TICKSPERSE to permit
|
|
|
|
|
precise modulation the sample periods.
|
|
|
|
|
|
2018-08-24 18:10:57 +02:00
|
|
|
|
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:
|
|
|
|
|
|
2020-05-10 15:13:21 +02:00
|
|
|
|
void nxsched_period_extclk(FAR struct timer_lowerhalf_s *lower);
|
2018-08-24 18:10:57 +02:00
|
|
|
|
|
|
|
|
|
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
|
2016-08-20 20:47:07 +02:00
|
|
|
|
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
|
|
|
|
|
|
2018-07-09 02:24:45 +02:00
|
|
|
|
CPULOAD_ONESHOT_NOMINAL is the nominal sample interval implied
|
2017-01-22 14:12:22 +01:00
|
|
|
|
by CONFIG_SCHED_CPULOAD_TICKSPERSEC in units of microseconds.
|
2018-08-24 18:10:57 +02:00
|
|
|
|
CPULOAD_ONESHOT_ENTROPY is (1 << CONFIG_CPULOAD_ENTROPY),
|
2018-06-16 19:36:27 +02:00
|
|
|
|
and 'error' is an error value that is retained from interval to
|
2016-08-20 20:47:07 +02:00
|
|
|
|
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
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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
|
2018-11-25 18:50:15 +01:00
|
|
|
|
select SCHED_SUSPENDSCHEDULER
|
|
|
|
|
select SCHED_RESUMESCHEDULER
|
2014-03-31 19:32:22 +02:00
|
|
|
|
---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):
|
|
|
|
|
|
2016-02-16 22:21:45 +01:00
|
|
|
|
void sched_note_start(FAR struct tcb_s *tcb);
|
|
|
|
|
void sched_note_stop(FAR struct tcb_s *tcb);
|
2021-12-03 05:26:42 +01:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2016-03-21 21:08:31 +01:00
|
|
|
|
void sched_note_suspend(FAR struct tcb_s *tcb);
|
|
|
|
|
void sched_note_resume(FAR struct tcb_s *tcb);
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
2016-11-28 00:14:57 +01:00
|
|
|
|
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);
|
|
|
|
|
|
2021-11-12 18:50:14 +01:00
|
|
|
|
NOTE: These are internal OS interfaces and are called at very
|
2016-03-17 16:49:43 +01:00
|
|
|
|
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.
|
|
|
|
|
|
2020-09-10 17:13:25 +02:00
|
|
|
|
config SCHED_INSTRUMENTATION_EXTERNAL
|
2020-09-10 13:45:11 +02:00
|
|
|
|
bool "System performance monitor endpoints are external"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
2021-02-25 13:48:46 +01:00
|
|
|
|
When this option is enabled, the board specific logic must implement all
|
2020-09-11 05:59:38 +02:00
|
|
|
|
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
|
2021-11-12 18:50:14 +01:00
|
|
|
|
-specific logic just needs to implement one callback:
|
2020-09-11 05:59:38 +02:00
|
|
|
|
|
|
|
|
|
void sched_note_add(FAR const void *note, size_t notelen);
|
|
|
|
|
|
|
|
|
|
and send the data to the suitable transport hardware.
|
2020-09-10 13:45:11 +02:00
|
|
|
|
|
2016-11-28 17:33:46 +01:00
|
|
|
|
config SCHED_INSTRUMENTATION_CPUSET
|
|
|
|
|
hex "CPU bit set"
|
|
|
|
|
default 0xffff
|
2020-07-23 15:18:03 +02:00
|
|
|
|
depends on SMP && SCHED_INSTRUMENTATION_FILTER
|
2016-11-28 17:33:46 +01:00
|
|
|
|
---help---
|
|
|
|
|
Monitor only CPUs in the bitset. Bit 0=CPU0, Bit1=CPU1, etc.
|
|
|
|
|
|
2016-02-16 22:21:45 +01:00
|
|
|
|
config SCHED_INSTRUMENTATION_PREEMPTION
|
2016-02-19 00:13:03 +01:00
|
|
|
|
bool "Preemption monitor hooks"
|
2016-02-16 22:21:45 +01:00
|
|
|
|
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
|
2016-02-19 00:13:03 +01:00
|
|
|
|
bool "Critical section monitor hooks"
|
2016-02-16 22:21:45 +01:00
|
|
|
|
default n
|
2018-11-26 00:22:33 +01:00
|
|
|
|
select IRQCOUNT
|
2016-02-16 22:21:45 +01:00
|
|
|
|
---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);
|
|
|
|
|
|
2017-01-12 15:03:36 +01:00
|
|
|
|
config SCHED_INSTRUMENTATION_SPINLOCKS
|
2016-11-28 17:33:46 +01:00
|
|
|
|
bool "Spinlock monitor hooks"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Enables additional hooks for spinlock state. Board-specific logic
|
|
|
|
|
must provide this additional logic.
|
|
|
|
|
|
2022-12-16 05:27:09 +01:00
|
|
|
|
void sched_note_spinlock(FAR struct tcb_s *tcb, FAR volatile spinlock_t *spinlock, int type)
|
2016-11-28 17:33:46 +01:00
|
|
|
|
|
2020-06-16 15:57:49 +02:00
|
|
|
|
config SCHED_INSTRUMENTATION_SYSCALL
|
|
|
|
|
bool "System call monitor hooks"
|
|
|
|
|
default n
|
2020-07-22 15:21:42 +02:00
|
|
|
|
depends on ARCH_HAVE_SYSCALL_HOOKS
|
2020-06-16 15:57:49 +02:00
|
|
|
|
---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);
|
|
|
|
|
|
2021-11-17 10:23:43 +01:00
|
|
|
|
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, ...);
|
|
|
|
|
|
2020-09-03 08:18:12 +02:00
|
|
|
|
config SCHED_INSTRUMENTATION_HIRES
|
|
|
|
|
bool "Use Hi-Res RTC for instrumentation"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Use higher resolution system timer for instrumentation.
|
|
|
|
|
|
2020-07-23 15:18:03 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2020-09-09 02:06:38 +02:00
|
|
|
|
config SCHED_INSTRUMENTATION_FILTER_DEFAULT_MODE
|
|
|
|
|
hex "Default instrumentation filter mode"
|
|
|
|
|
depends on SCHED_INSTRUMENTATION_FILTER
|
2022-02-18 08:05:23 +01:00
|
|
|
|
default 0x3f
|
2020-09-09 02:06:38 +02:00
|
|
|
|
---help---
|
|
|
|
|
Default mode of the instrumentation filter logic.
|
|
|
|
|
Bit 0 = Enable instrumentation
|
2022-02-18 08:05:23 +01:00
|
|
|
|
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
|
2020-09-09 02:06:38 +02:00
|
|
|
|
|
2016-02-16 22:21:45 +01:00
|
|
|
|
endif # SCHED_INSTRUMENTATION
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endmenu # Performance Monitoring
|
|
|
|
|
|
|
|
|
|
menu "Files and I/O"
|
|
|
|
|
|
|
|
|
|
config DEV_CONSOLE
|
|
|
|
|
bool "Enable /dev/console"
|
|
|
|
|
default y
|
|
|
|
|
---help---
|
2014-04-09 18:57:56 +02:00
|
|
|
|
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.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config FDCLONE_DISABLE
|
2012-04-11 19:13:04 +02:00
|
|
|
|
bool "Disable cloning of file descriptors"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2014-04-09 18:57:56 +02:00
|
|
|
|
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.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config FDCLONE_STDIO
|
2012-04-11 19:13:04 +02:00
|
|
|
|
bool "Disable clone file descriptors without stdio"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2021-03-16 13:13:02 +01:00
|
|
|
|
config NFILE_DESCRIPTORS_PER_BLOCK
|
|
|
|
|
int "The number of file descriptors per block"
|
|
|
|
|
default 8
|
2019-02-11 19:09:26 +01:00
|
|
|
|
range 3 99999
|
2014-03-31 19:32:22 +02:00
|
|
|
|
---help---
|
2021-03-16 13:13:02 +01:00
|
|
|
|
The number of file descriptors per block(one for each open)
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
2020-08-13 12:17:29 +02:00
|
|
|
|
config FILE_STREAM
|
|
|
|
|
bool "Enable FILE stream"
|
|
|
|
|
default y
|
2014-03-31 19:32:22 +02:00
|
|
|
|
---help---
|
2020-08-13 12:17:29 +02:00
|
|
|
|
Enable the standard buffered input/output support
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
config NAME_MAX
|
|
|
|
|
int "Maximum size of a file name"
|
|
|
|
|
default 32
|
|
|
|
|
---help---
|
2020-02-11 09:03:48 +01:00
|
|
|
|
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.
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
endmenu # Files and I/O
|
|
|
|
|
|
|
|
|
|
menuconfig PRIORITY_INHERITANCE
|
2021-07-23 07:47:26 +02:00
|
|
|
|
bool "Enable priority inheritance"
|
2012-08-02 02:42:46 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2014-03-31 19:32:22 +02:00
|
|
|
|
Set to enable support for priority inheritance on mutexes and semaphores.
|
2016-11-06 16:06:37 +01:00
|
|
|
|
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
|
2019-08-19 02:04:08 +02:00
|
|
|
|
is used for signaling). In such cases, priority inheritance can be
|
2016-11-06 16:06:37 +01:00
|
|
|
|
disabled for individual semaphores by calling:
|
|
|
|
|
|
|
|
|
|
int ret = sem_setprotocol(&sem, SEM_PRIO_NONE);
|
|
|
|
|
|
2017-10-03 23:35:24 +02:00
|
|
|
|
From applications, the functionally equivalent OS internal interface,
|
2020-05-17 15:56:21 +02:00
|
|
|
|
nxsem_set_protocol(), should be used within the OS
|
2017-10-03 23:35:24 +02:00
|
|
|
|
|
2016-11-06 16:06:37 +01:00
|
|
|
|
And for individual pthread mutexes by setting the protocol attribute
|
|
|
|
|
before initializing the mutex:
|
|
|
|
|
|
|
|
|
|
int ret = pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_NONE);
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
if PRIORITY_INHERITANCE
|
|
|
|
|
|
|
|
|
|
config SEM_PREALLOCHOLDERS
|
|
|
|
|
int "Number of pre-allocated holders"
|
2021-11-07 16:00:01 +01:00
|
|
|
|
default 4 if DEFAULT_SMALL
|
|
|
|
|
default 8 if !DEFAULT_SMALL
|
2014-03-31 19:32:22 +02:00
|
|
|
|
---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.
|
|
|
|
|
|
|
|
|
|
endif # PRIORITY_INHERITANCE
|
|
|
|
|
|
|
|
|
|
menu "RTOS hooks"
|
|
|
|
|
|
2019-02-18 23:25:08 +01:00
|
|
|
|
config BOARD_EARLY_INITIALIZE
|
|
|
|
|
bool "Custom board early initialization"
|
2014-03-31 19:32:22 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2019-02-19 00:36:11 +01:00
|
|
|
|
There are three points in time where you can insert custom,
|
|
|
|
|
board-specific initialization logic:
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
2019-02-18 22:32:00 +01:00
|
|
|
|
1) <arch>_board_initialize(): This function is used only for
|
2014-03-31 19:32:22 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2019-02-18 22:32:00 +01:00
|
|
|
|
At this same point in time, the OS will also call a board-
|
2019-02-18 23:25:08 +01:00
|
|
|
|
specific initialization function named board_early_initialize()
|
2019-02-19 00:36:11 +01:00
|
|
|
|
if CONFIG_BOARD_EARLY_INITIALIZE is selected. The context in
|
2019-02-18 23:25:08 +01:00
|
|
|
|
which board_early_initialize() executes is suitable for early
|
2019-02-18 22:32:00 +01:00
|
|
|
|
initialization of most, simple device drivers and is a logical,
|
|
|
|
|
board-specific extension of up_initialize().
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
2019-02-18 23:25:08 +01:00
|
|
|
|
board_early_initialize() runs on the startup, initialization thread.
|
2019-02-18 22:32:00 +01:00
|
|
|
|
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.
|
|
|
|
|
|
2020-02-22 19:31:14 +01:00
|
|
|
|
Waiting for events, use of I2C, SPI, etc are permissible in the
|
2019-02-18 22:32:00 +01:00
|
|
|
|
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---
|
2019-02-19 00:36:11 +01:00
|
|
|
|
There are three points in time where you can insert custom,
|
|
|
|
|
board-specific initialization logic:
|
2019-02-18 22:32:00 +01:00
|
|
|
|
|
|
|
|
|
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.
|
2012-08-02 02:42:46 +02:00
|
|
|
|
|
2019-02-18 22:32:00 +01:00
|
|
|
|
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-
|
2019-02-18 23:25:08 +01:00
|
|
|
|
specific initialization function named board_early_initialize()
|
2019-02-19 00:36:11 +01:00
|
|
|
|
if CONFIG_BOARD_EARLY_INITIALIZE is selected. The context in
|
2019-02-18 23:25:08 +01:00
|
|
|
|
which board_early_initialize() executes is suitable for early
|
2019-02-18 22:32:00 +01:00
|
|
|
|
initialization of most, simple device drivers and is a logical,
|
|
|
|
|
board-specific extension of up_initialize().
|
|
|
|
|
|
2019-02-18 23:25:08 +01:00
|
|
|
|
board_early_initialize() runs on the startup, initialization thread.
|
2014-09-04 02:36:43 +02:00
|
|
|
|
Some initialization operations cannot be performed on the start-up,
|
|
|
|
|
initialization thread. That is because the initialization thread
|
2019-02-13 02:13:22 +01:00
|
|
|
|
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.
|
2019-02-18 22:32:00 +01:00
|
|
|
|
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.
|
|
|
|
|
|
2020-02-22 19:31:14 +01:00
|
|
|
|
Waiting for events, use of I2C, SPI, etc are permissible in the
|
2019-02-18 22:32:00 +01:00
|
|
|
|
context of board_late_initialize(). That is because
|
|
|
|
|
board_late_initialize() will run on a temporary, internal kernel
|
|
|
|
|
thread.
|
2014-09-04 02:36:43 +02:00
|
|
|
|
|
2019-02-18 22:32:00 +01:00
|
|
|
|
if BOARD_LATE_INITIALIZE
|
2014-09-04 02:36:43 +02:00
|
|
|
|
|
|
|
|
|
config BOARD_INITTHREAD_STACKSIZE
|
|
|
|
|
int "Board initialization thread stack size"
|
2020-03-27 02:51:03 +01:00
|
|
|
|
default DEFAULT_TASK_STACKSIZE
|
2014-09-04 02:36:43 +02:00
|
|
|
|
---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.
|
|
|
|
|
|
2019-02-18 22:32:00 +01:00
|
|
|
|
endif # BOARD_LATE_INITIALIZE
|
2014-09-04 02:36:43 +02:00
|
|
|
|
|
2013-01-27 16:52:58 +01:00
|
|
|
|
config SCHED_STARTHOOK
|
|
|
|
|
bool "Enable startup hook"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
This commit renames all internal OS functions defined under sched/task so that they begin with the prefix. For example, nxtask_exit() vs. task_exit().
Squashed commit of the following:
Trivial, cosmetic
sched/, arch/, and include: Rename task_vforkstart() as nxtask_vforkstart()
sched/, arch/, and include: Rename task_vforkabort() as nxtask_vforkabort()
sched/, arch/, and include: Rename task_vforksetup() as nxtask_vfork_setup()
sched/: Rename notify_cancellation() as nxnotify_cancellation()
sched/: Rename task_recover() to nxtask_recover()
sched/task, sched/pthread/, Documentation/: Rename task_argsetup() and task_terminate() to nxtask_argsetup() and nxtask_terminate(), respectively.
sched/task: Rename task_schedsetup() to nxtask_schedsetup()
sched/ (plus some binfmt/, include/, and arch/): Rename task_start() and task_starthook() to nxtask_start() and nxtask_starthook().
arch/ and sched/: Rename task_exit() and task_exithook() to nxtask_exit() and nxtask_exithook(), respectively.
sched/task: Rename all internal, static, functions to begin with the nx prefix.
2019-02-04 20:42:51 +01:00
|
|
|
|
Enable a non-standard, internal OS API call nxtask_starthook().
|
|
|
|
|
nxtask_starthook() registers a function that will be called on task
|
2013-01-27 16:52:58 +01:00
|
|
|
|
startup before that actual task entry point is called. The
|
|
|
|
|
starthook is useful, for example, for setting up automatic
|
|
|
|
|
configuration of C++ constructors.
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endmenu # RTOS hooks
|
2012-08-30 22:13:50 +02:00
|
|
|
|
|
2018-08-27 19:40:09 +02:00
|
|
|
|
menu "Signal Configuration"
|
|
|
|
|
|
2020-12-14 10:33:38 +01:00
|
|
|
|
config SIG_PREALLOC_IRQ_ACTIONS
|
|
|
|
|
int "Number of pre-allocated irq actions"
|
2021-11-07 16:00:01 +01:00
|
|
|
|
default 4 if DEFAULT_SMALL
|
|
|
|
|
default 8 if !DEFAULT_SMALL
|
2020-12-14 10:33:38 +01:00
|
|
|
|
---help---
|
|
|
|
|
The number of pre-allocated irq action structures.
|
|
|
|
|
|
2015-12-30 20:20:31 +01:00
|
|
|
|
config SIG_EVTHREAD
|
2022-03-10 19:10:58 +01:00
|
|
|
|
bool "Support SIGEV_THREAD"
|
2015-12-30 20:20:31 +01:00
|
|
|
|
default n
|
2021-08-05 08:29:17 +02:00
|
|
|
|
depends on !BUILD_KERNEL && SCHED_WORKQUEUE
|
2021-08-01 09:27:08 +02:00
|
|
|
|
select LIBC_USRWORK if BUILD_PROTECTED
|
2015-12-30 20:20:31 +01:00
|
|
|
|
---help---
|
|
|
|
|
Built in support for the SIGEV_THREAD signal deliver method.
|
|
|
|
|
|
2015-12-30 22:01:14 +01:00
|
|
|
|
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.
|
2015-12-30 20:20:31 +01:00
|
|
|
|
|
2019-08-26 18:54:49 +02:00
|
|
|
|
config SIG_EVTHREAD_HPWORK
|
|
|
|
|
bool "SIGEV_EVTHREAD use HPWORK"
|
|
|
|
|
default n
|
2022-01-06 19:03:48 +01:00
|
|
|
|
depends on SIG_EVTHREAD && SCHED_HPWORK
|
2019-08-26 18:54:49 +02:00
|
|
|
|
---help---
|
2022-03-10 19:10:58 +01:00
|
|
|
|
if selected, SIGEV_THREAD will use the high priority work queue.
|
2019-08-26 18:54:49 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2018-08-27 23:37:43 +02:00
|
|
|
|
menuconfig SIG_DEFAULT
|
2018-08-27 19:40:09 +02:00
|
|
|
|
bool "Default signal actions"
|
2018-08-26 16:49:08 +02:00
|
|
|
|
default n
|
|
|
|
|
---help---
|
2018-08-27 19:40:09 +02:00
|
|
|
|
Enable to support default signal actions.
|
2018-08-26 16:49:08 +02:00
|
|
|
|
|
2018-08-27 23:37:43 +02:00
|
|
|
|
if SIG_DEFAULT
|
|
|
|
|
|
|
|
|
|
comment "Per-signal Default Actions"
|
|
|
|
|
|
|
|
|
|
config SIG_SIGUSR1_ACTION
|
|
|
|
|
bool "SIGUSR1"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Enable the default action for SIGUSR1 (terminate the task)
|
2018-08-27 23:37:43 +02:00
|
|
|
|
Make sure that your applications are expecting this POSIX behavior.
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Backward compatible behavior would require that the application use
|
|
|
|
|
sigaction() to ignore SIGUSR1.
|
2018-08-27 23:37:43 +02:00
|
|
|
|
|
|
|
|
|
config SIG_SIGUSR2_ACTION
|
|
|
|
|
bool "SIGUSR2"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Enable the default action for SIGUSR2 (terminate the task)
|
2018-08-27 23:37:43 +02:00
|
|
|
|
Make sure that your applications are expecting this POSIX behavior.
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Backward compatible behavior would require that the application use
|
|
|
|
|
sigaction() to ignore SIGUSR2.
|
2018-08-27 23:37:43 +02:00
|
|
|
|
|
|
|
|
|
config SIG_SIGALRM_ACTION
|
|
|
|
|
bool "SIGALRM"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Enable the default action for SIGALRM (terminate the task)
|
2018-08-27 23:37:43 +02:00
|
|
|
|
Make sure that your applications are expecting this POSIX behavior.
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Backward compatible behavior would require that the application use
|
|
|
|
|
sigaction() to ignore SIGALRM.
|
2018-08-27 23:37:43 +02:00
|
|
|
|
|
|
|
|
|
config SIG_SIGPOLL_ACTION
|
|
|
|
|
bool "SIGPOLL"
|
|
|
|
|
default n
|
|
|
|
|
depends on FS_AIO
|
|
|
|
|
---help---
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Enable the default action for SIGPOLL (terminate the task)
|
2018-08-27 23:37:43 +02:00
|
|
|
|
Make sure that your applications are expecting this POSIX behavior.
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Backward compatible behavior would require that the application use
|
|
|
|
|
sigaction() to ignore SIGPOLL.
|
|
|
|
|
|
|
|
|
|
config SIG_SIGSTOP_ACTION
|
2020-10-29 05:53:41 +01:00
|
|
|
|
bool "SIGSTOP SIGTSTP, and SIGCONT"
|
2018-08-30 18:27:18 +02:00
|
|
|
|
default y
|
|
|
|
|
---help---
|
2020-10-29 05:53:41 +01:00
|
|
|
|
Enable the default action for SIGSTOP and SIGTSTP (suspend the
|
2018-08-30 18:27:18 +02:00
|
|
|
|
task) and SIGCONT (resume the task).
|
|
|
|
|
|
|
|
|
|
config SIG_SIGKILL_ACTION
|
2020-07-14 05:21:03 +02:00
|
|
|
|
bool "SIGINT SIGKILL SIGQUIT and SIGTERM"
|
2018-08-30 18:27:18 +02:00
|
|
|
|
default y
|
|
|
|
|
---help---
|
|
|
|
|
Enable the default action for SIGINT and SIGKILL (terminate the
|
|
|
|
|
task).
|
2018-08-27 23:37:43 +02:00
|
|
|
|
|
2019-10-17 19:29:39 +02:00
|
|
|
|
config SIG_SIGPIPE_ACTION
|
|
|
|
|
bool "SIGPIPE"
|
|
|
|
|
default y
|
|
|
|
|
---help---
|
|
|
|
|
Enable the default action for SIGPIPE (terminate the task).
|
|
|
|
|
|
2018-08-27 23:37:43 +02:00
|
|
|
|
endif # SIG_DEFAULT
|
2018-08-26 16:49:08 +02:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
menu "Signal Numbers"
|
2013-01-12 20:58:45 +01:00
|
|
|
|
|
2018-08-27 23:37:43 +02:00
|
|
|
|
comment "Standard Signal Numbers"
|
|
|
|
|
|
2013-01-12 20:58:45 +01:00
|
|
|
|
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
|
|
|
|
|
|
2018-08-27 23:37:43 +02:00
|
|
|
|
config SIG_SIGALRM
|
2013-01-12 20:58:45 +01:00
|
|
|
|
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
|
|
|
|
|
|
2014-10-05 14:02:37 +02:00
|
|
|
|
config SIG_POLL
|
|
|
|
|
int "SIGPOLL"
|
|
|
|
|
default 5
|
2014-10-05 23:44:43 +02:00
|
|
|
|
depends on FS_AIO
|
2014-10-05 14:02:37 +02:00
|
|
|
|
---help---
|
|
|
|
|
The SIGPOLL signal is sent to a process when an asynchronous I/O
|
|
|
|
|
event occurs (meaning it has been polled). Default: 5
|
|
|
|
|
|
2018-08-30 18:27:18 +02:00
|
|
|
|
if SIG_DEFAULT
|
|
|
|
|
|
|
|
|
|
config SIG_STOP
|
|
|
|
|
int "SIGSTOP"
|
2018-08-28 20:15:31 +02:00
|
|
|
|
default 6
|
|
|
|
|
---help---
|
2018-08-30 18:27:18 +02:00
|
|
|
|
Suspend/pause a task. SIGSTOP may not be caught or ignored.
|
|
|
|
|
|
2020-10-29 05:53:41 +01:00
|
|
|
|
config SIG_TSTP
|
|
|
|
|
int "SIGTSTP"
|
2018-08-30 18:27:18 +02:00
|
|
|
|
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.
|
2018-08-28 20:15:31 +02:00
|
|
|
|
|
2018-08-26 16:49:08 +02:00
|
|
|
|
config SIG_KILL
|
|
|
|
|
int "SIGKILL"
|
|
|
|
|
default 9
|
2018-08-30 18:27:18 +02:00
|
|
|
|
---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
|
2018-08-26 16:49:08 +02:00
|
|
|
|
---help---
|
2018-08-30 18:27:18 +02:00
|
|
|
|
The SIGINT signal is sent to cause a task termination event.
|
|
|
|
|
SIGINT may be ignored or caught by the receiving task.
|
|
|
|
|
|
2020-07-14 05:21:03 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2018-08-30 18:27:18 +02:00
|
|
|
|
endif # SIG_DEFAULT
|
2018-08-26 16:49:08 +02:00
|
|
|
|
|
2019-10-17 19:29:39 +02:00
|
|
|
|
config SIG_PIPE
|
|
|
|
|
int "SIGPIPE"
|
2020-10-26 03:27:41 +01:00
|
|
|
|
default 13
|
2019-10-17 19:29:39 +02:00
|
|
|
|
---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.
|
|
|
|
|
|
2022-06-02 09:17:23 +02:00
|
|
|
|
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.
|
|
|
|
|
|
2018-08-27 23:37:43 +02:00
|
|
|
|
comment "Non-standard Signal Numbers"
|
|
|
|
|
|
2013-01-12 20:58:45 +01:00
|
|
|
|
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
|
2021-08-01 09:27:08 +02:00
|
|
|
|
depends on SCHED_WORKQUEUE || LIBC_USRWORK
|
2013-01-12 20:58:45 +01:00
|
|
|
|
---help---
|
2021-06-30 23:24:01 +02:00
|
|
|
|
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
|
2013-01-12 20:58:45 +01:00
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endmenu # Signal Numbers
|
2018-08-27 19:40:09 +02:00
|
|
|
|
endmenu # Signal Configuration
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2022-10-19 16:28:43 +02:00
|
|
|
|
menu "Message Queue Options"
|
2022-11-16 11:20:31 +01:00
|
|
|
|
depends on !DISABLE_MQUEUE || !DISABLE_MQUEUE_SYSV
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config PREALLOC_MQ_MSGS
|
2013-01-17 15:43:55 +01:00
|
|
|
|
int "Number of pre-allocated messages"
|
2021-11-07 16:00:01 +01:00
|
|
|
|
default 4 if DEFAULT_SMALL
|
|
|
|
|
default 8 if !DEFAULT_SMALL
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
The number of pre-allocated message structures. The system manages
|
|
|
|
|
a pool of preallocated message structures to minimize dynamic allocations
|
|
|
|
|
|
2020-12-14 08:42:22 +01:00
|
|
|
|
config PREALLOC_MQ_IRQ_MSGS
|
|
|
|
|
int "Number of pre-allocated irq messages"
|
2021-11-07 16:00:01 +01:00
|
|
|
|
default 4 if DEFAULT_SMALL
|
|
|
|
|
default 8 if !DEFAULT_SMALL
|
2020-12-14 08:42:22 +01:00
|
|
|
|
---help---
|
|
|
|
|
The number of pre-allocated irq message structures.
|
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config MQ_MAXMSGSIZE
|
2012-04-11 19:13:04 +02:00
|
|
|
|
int "Maximum message size"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default 32
|
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
Message structures are allocated with a fixed payload size given by this
|
|
|
|
|
setting (does not include other message structure overhead.
|
|
|
|
|
|
2022-06-09 09:19:01 +02:00
|
|
|
|
config DISABLE_MQUEUE_NOTIFICATION
|
|
|
|
|
bool "Disable POSIX message queue notification"
|
|
|
|
|
default DEFAULT_SMALL
|
|
|
|
|
---help---
|
|
|
|
|
Disable POSIX message queue notification
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
endmenu # POSIX Message Queue Options
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2017-01-29 15:55:27 +01:00
|
|
|
|
config MODULE
|
2015-12-12 14:09:17 +01:00
|
|
|
|
bool "Enable loadable OS modules"
|
|
|
|
|
default n
|
2017-01-29 15:55:27 +01:00
|
|
|
|
select LIBC_MODLIB
|
2021-06-18 01:47:45 +02:00
|
|
|
|
select ARCH_USE_TEXT_HEAP if ARCH_HAVE_TEXT_HEAP
|
2015-12-12 14:09:17 +01:00
|
|
|
|
---help---
|
|
|
|
|
Enable support for loadable OS modules. Default: n
|
|
|
|
|
|
|
|
|
|
menu "Work queue support"
|
2014-10-11 23:50:22 +02:00
|
|
|
|
|
|
|
|
|
config SCHED_WORKQUEUE
|
|
|
|
|
# bool "Enable worker thread"
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Create dedicated "worker" threads to handle delayed or asynchronous
|
|
|
|
|
processing.
|
|
|
|
|
|
2019-01-27 18:02:56 +01:00
|
|
|
|
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.
|
|
|
|
|
|
2014-10-11 23:50:22 +02:00
|
|
|
|
config SCHED_HPWORK
|
|
|
|
|
bool "High priority (kernel) worker thread"
|
2014-10-15 00:56:37 +02:00
|
|
|
|
default n
|
2014-10-11 23:50:22 +02:00
|
|
|
|
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
|
|
|
|
|
|
2018-08-25 22:52:13 +02:00
|
|
|
|
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
|
|
|
|
|
|
2014-10-12 15:09:57 +02:00
|
|
|
|
config SCHED_HPWORKPRIORITY
|
2014-10-11 23:50:22 +02:00
|
|
|
|
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
|
2014-10-14 18:21:18 +02:00
|
|
|
|
priority thread in your system. Default: 224
|
2014-10-11 23:50:22 +02:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2014-10-12 15:09:57 +02:00
|
|
|
|
config SCHED_HPWORKSTACKSIZE
|
2014-10-11 23:50:22 +02:00
|
|
|
|
int "High priority worker thread stack size"
|
2020-03-27 02:51:03 +01:00
|
|
|
|
default DEFAULT_TASK_STACKSIZE
|
2014-10-11 23:50:22 +02:00
|
|
|
|
---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
|
2014-10-14 18:21:18 +02:00
|
|
|
|
essentially a "thread pool" that provides multi-threaded servicing
|
|
|
|
|
of the low-priority work queue. This breaks the serialization
|
2014-10-11 23:50:22 +02:00
|
|
|
|
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.
|
2017-03-03 16:20:02 +01:00
|
|
|
|
Such behavior is necessary to support asynchronous I/O, AIO (for
|
|
|
|
|
example).
|
|
|
|
|
|
2017-03-04 18:33:36 +01:00
|
|
|
|
CAUTION: Some drivers may use the work queue to serialize
|
2018-08-25 22:52:13 +02:00
|
|
|
|
operations. They may also use the low-priority work queue if it is
|
|
|
|
|
available. If there are multiple low-priority worker threads, then
|
2017-03-04 18:33:36 +01:00
|
|
|
|
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
|
2014-10-11 23:50:22 +02:00
|
|
|
|
|
|
|
|
|
config SCHED_LPWORKPRIORITY
|
|
|
|
|
int "Low priority worker thread priority"
|
2018-09-11 16:49:39 +02:00
|
|
|
|
default 100
|
2014-10-11 23:50:22 +02:00
|
|
|
|
---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
|
2018-09-11 16:49:39 +02:00
|
|
|
|
adjusted to match the highest priority client. Default: 100
|
2014-10-11 23:50:22 +02:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2014-10-14 18:21:18 +02:00
|
|
|
|
This value provides an upper limit on the priority of the lower
|
2014-10-11 23:50:22 +02:00
|
|
|
|
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"
|
2020-03-27 02:51:03 +01:00
|
|
|
|
default DEFAULT_TASK_STACKSIZE
|
2014-10-11 23:50:22 +02:00
|
|
|
|
---help---
|
|
|
|
|
The stack size allocated for the lower priority worker thread. Default: 2K.
|
|
|
|
|
|
|
|
|
|
endif # SCHED_LPWORK
|
|
|
|
|
endmenu # Work Queue Support
|
|
|
|
|
|
2014-03-31 19:32:22 +02:00
|
|
|
|
menu "Stack and heap information"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
|
2021-03-30 14:33:58 +02:00
|
|
|
|
config DEFAULT_TASK_STACKSIZE
|
|
|
|
|
int "The default stack size for tasks"
|
|
|
|
|
default 2048
|
|
|
|
|
---help---
|
|
|
|
|
The default stack size for tasks.
|
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config IDLETHREAD_STACKSIZE
|
2012-04-11 19:13:04 +02:00
|
|
|
|
int "Idle thread stack size"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default 1024
|
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
The size of the initial stack used by the IDLE thread. The IDLE thread
|
2014-08-30 19:14:51 +02:00
|
|
|
|
is the thread that (1) performs the initial boot of the system up to the
|
2018-07-09 02:24:45 +02:00
|
|
|
|
point where start-up application is spawned, and (2) there after is the
|
2014-08-30 19:14:51 +02:00
|
|
|
|
IDLE thread that executes only when there is no other thread ready to run.
|
2012-04-11 19:13:04 +02:00
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config PTHREAD_STACK_MIN
|
2012-04-11 19:13:04 +02:00
|
|
|
|
int "Minimum pthread stack size"
|
2012-04-07 16:50:57 +02:00
|
|
|
|
default 256
|
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
Minimum pthread stack size
|
|
|
|
|
|
2012-04-07 16:50:57 +02:00
|
|
|
|
config PTHREAD_STACK_DEFAULT
|
2012-04-11 19:13:04 +02:00
|
|
|
|
int "Default pthread stack size"
|
2020-03-27 02:51:03 +01:00
|
|
|
|
default DEFAULT_TASK_STACKSIZE
|
2012-04-07 16:50:57 +02:00
|
|
|
|
---help---
|
2012-04-11 19:13:04 +02:00
|
|
|
|
Default pthread stack size
|
2014-03-31 19:32:22 +02:00
|
|
|
|
|
|
|
|
|
endmenu # Stack and heap information
|
2021-07-30 06:05:33 +02:00
|
|
|
|
|
|
|
|
|
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
|