2c0e2ac36b
Record all memory allocation and release, save to ram, used to analyze memory allocation rate and memory usage Its absolute value is not trustworthy because the memory will be allocated in thread A and released in thread B netinit-5 [0] 0.105984392: tracing_mark_write: C|5|Heap Usage|96|free: heap: 0x606000000020 size:24, address: 0x603000000370 netinit-5 [0] 0.105996874: tracing_mark_write: C|5|Heap Usage|24|free: heap: 0x606000000020 size:72, address: 0x6070000008e0 nsh_main-4 [0] 3.825169408: tracing_mark_write: C|4|Heap Usage|2177665|free: heap: 0x606000000020 size:424, address: 0x614000000840 nsh_main-4 [0] 3.825228525: tracing_mark_write: C|4|Heap Usage|14977|free: heap: 0x606000000020 size:2162688, address: 0x7f80a639f800 nsh_main-4 [0] 3.825298789: tracing_mark_write: C|4|Heap Usage|15189|malloc: heap: 0x606000000020 size:20, address: 0x6030000003a0 Signed-off-by: yinshengkai <yinshengkai@xiaomi.com> Signed-off-by: Neo Xu <neo.xu1990@gmail.com>
2008 lines
66 KiB
Plaintext
2008 lines
66 KiB
Plaintext
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
|
#
|
|
|
|
menuconfig DISABLE_OS_API
|
|
bool "Disable NuttX interfaces"
|
|
default y
|
|
---help---
|
|
The following can be used to disable categories of
|
|
APIs supported by the OS. If the compiler supports
|
|
weak functions, then it should not be necessary to
|
|
disable functions unless you want to restrict usage
|
|
of those APIs.
|
|
|
|
if DISABLE_OS_API
|
|
|
|
config DISABLE_POSIX_TIMERS
|
|
bool "Disable POSIX timers"
|
|
default DEFAULT_SMALL
|
|
---help---
|
|
Disable support for the the entire POSIX timer family
|
|
including timer_create(), timer_gettime(), timer_settime(),
|
|
etc.
|
|
|
|
NOTE: This option will also disable getitimer() and
|
|
setitimer() which are not, strictly speaking, POSIX timers.
|
|
|
|
config DISABLE_PTHREAD
|
|
bool "Disable pthread support"
|
|
default DEFAULT_SMALL
|
|
|
|
config DISABLE_MQUEUE
|
|
bool "Disable POSIX message queue support"
|
|
default DEFAULT_SMALL
|
|
|
|
config DISABLE_MQUEUE_SYSV
|
|
bool "Disable System V message queue support"
|
|
default DISABLE_MQUEUE
|
|
---help---
|
|
Disable System V message queue support
|
|
|
|
config DISABLE_ENVIRON
|
|
bool "Disable environment variable support"
|
|
default DEFAULT_SMALL
|
|
|
|
endif # DISABLE_OS_API
|
|
|
|
config DISABLE_IDLE_LOOP
|
|
bool "Disable idle loop support"
|
|
default n
|
|
---help---
|
|
This option allows nx_start to return instead of
|
|
entering the idle loop.
|
|
|
|
menu "Clocks and Timers"
|
|
|
|
config ARCH_HAVE_TICKLESS
|
|
bool
|
|
|
|
config SCHED_TICKLESS
|
|
bool "Support tick-less OS"
|
|
default n
|
|
depends on ARCH_HAVE_TICKLESS
|
|
---help---
|
|
By default, system time is driven by a periodic timer interrupt. An
|
|
alternative configurations is a tick-less configuration in which
|
|
there is no periodic timer interrupt. Instead an interval timer is
|
|
used to schedule the next OS time event. This option selects that
|
|
tick-less OS option. If the tick-less OS is selected, then there are
|
|
additional platform specific interfaces that must be provided as
|
|
defined in include/nuttx/arch.h
|
|
|
|
if SCHED_TICKLESS
|
|
|
|
config SCHED_TICKLESS_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);
|
|
|
|
config SCHED_TICKLESS_ALARM
|
|
bool "Tickless alarm"
|
|
default n
|
|
---help---
|
|
The tickless option can be supported either via a simple interval
|
|
timer (plus elapsed time) or via an alarm. The interval timer allows
|
|
programming events to occur after an interval. With the alarm,
|
|
you can set a time in the future and get an event when that alarm
|
|
goes off. This option selects the use of an alarm.
|
|
|
|
The advantage of an alarm is that it avoids some small timing
|
|
errors; the advantage of the use of the interval timer is that
|
|
the hardware requirement may be less.
|
|
|
|
config SCHED_TICKLESS_LIMIT_MAX_SLEEP
|
|
bool "Max sleep period (in microseconds)"
|
|
default n
|
|
---help---
|
|
Enables use of the g_oneshot_maxticks variable. This variable is
|
|
initialized by platform-specific logic at runtime to the maximum
|
|
delay that the timer can wait (in configured clock ticks). The
|
|
RTOS tickless logic will then limit all requested delays to this
|
|
value.
|
|
|
|
endif
|
|
|
|
config USEC_PER_TICK
|
|
int "System timer tick period (microseconds)"
|
|
default 10000 if !SCHED_TICKLESS
|
|
default 100 if SCHED_TICKLESS
|
|
---help---
|
|
In the "normal" configuration where system time is provided by a
|
|
periodic timer interrupt, the default system timer is expected to
|
|
run at 100Hz or USEC_PER_TICK=10000. This setting must be defined
|
|
to inform of NuttX the interval that the processor hardware is
|
|
providing system timer interrupts to the OS.
|
|
|
|
If SCHED_TICKLESS is selected, then there are no system timer
|
|
interrupts. In this case, USEC_PER_TICK does not control any timer
|
|
rates. Rather, it only determines the resolution of time reported
|
|
by clock_systime_ticks() and the resolution of times that can be set for
|
|
certain delays including watchdog timers and delayed work. In this
|
|
case there is a trade-off: It is better to have the USEC_PER_TICK as
|
|
low as possible for higher timing resolution. However, the time
|
|
is currently held in 'unsigned int' on some systems, this may be
|
|
16-bits but on most contemporary systems it will be 32-bits. In
|
|
either case, smaller values of USEC_PER_TICK will reduce the range
|
|
of values that delays that can be represented. So the trade-off is
|
|
between range and resolution (you could also modify the code to use
|
|
a 64-bit value if you really want both).
|
|
|
|
The default, 100 microseconds, will provide for a range of delays
|
|
up to 120 hours.
|
|
|
|
This value should never be less than the underlying resolution of
|
|
the timer. Error may ensue.
|
|
|
|
if !SCHED_TICKLESS
|
|
|
|
config SYSTEMTICK_EXTCLK
|
|
bool "Use external clock"
|
|
default n
|
|
depends on ARCH_HAVE_EXTCLK
|
|
---help---
|
|
Use external clock for system tick. When enabled, the platform-specific
|
|
logic must start its own timer interrupt to make periodic calls to the
|
|
nxsched_process_timer() or the functions called within. The purpose is
|
|
to move the scheduling off the processor clock to allow entering low
|
|
power states that would disable that clock.
|
|
|
|
config SYSTEMTICK_HOOK
|
|
bool "System timer hook"
|
|
default n
|
|
---help---
|
|
Enable a call to a user-provided, board-level function on each timer
|
|
tick. This permits custom actions that may be performed on each
|
|
timer tick. The form of the user-provided function is:
|
|
|
|
void board_timerhook(void);
|
|
|
|
(prototyped in include/nuttx/board.h).
|
|
|
|
endif # !SCHED_TICKLESS
|
|
|
|
config SYSTEM_TIME64
|
|
bool "64-bit system clock"
|
|
default n
|
|
---help---
|
|
The system timer is incremented at the rate determined by
|
|
USEC_PER_TICK, typically at 100Hz. The count at any given time is
|
|
then the "uptime" in units of system timer ticks. By default, the
|
|
system time is 32-bits wide. Those defaults provide a range of about
|
|
497 days which is probably a sufficient range for "uptime".
|
|
|
|
However, if the system timer rate is significantly higher than 100Hz
|
|
and/or if a very long "uptime" is required, then this option can be
|
|
selected to support a 64-bit wide timer.
|
|
|
|
config ARCH_HAVE_ADJTIME
|
|
bool
|
|
default n
|
|
|
|
config CLOCK_ADJTIME
|
|
bool "Support adjtime function"
|
|
default n
|
|
depends on ARCH_HAVE_ADJTIME || RTC_ADJTIME
|
|
---help---
|
|
Enables usage of adjtime() interface used to correct the system time
|
|
clock. This requires specific architecture support.
|
|
|
|
Adjustment can affect system timer period and/or high-resolution RTC.
|
|
These are implemented by interfaces up_adjtime() and up_rtc_adjtime().
|
|
|
|
This is not a POSIX interface but derives from 4.3BSD, System V.
|
|
It is also supported for Linux compatibility.
|
|
|
|
if CLOCK_ADJTIME
|
|
|
|
config CLOCK_ADJTIME_SLEWLIMIT_PPM
|
|
int "Adjtime slew limit"
|
|
default 20000
|
|
range 1 1000000
|
|
---help---
|
|
Set limit of adjtime() clock slewing as parts per million.
|
|
|
|
In real time systems we do not want the time to adjust too quickly.
|
|
For example CLOCK_ADJTIME_SLEWLIMIT=1000 will slow or speed the timer
|
|
tick period by at most 0.1 percent of the nominal value.
|
|
|
|
config CLOCK_ADJTIME_PERIOD_MS
|
|
int "Adjtime period"
|
|
default 970
|
|
range 1 3600000
|
|
---help---
|
|
Define system clock adjustment period in milliseconds.
|
|
The adjustment commanded by adjtime() call is applied over this time period.
|
|
|
|
endif
|
|
|
|
config ARCH_HAVE_TIMEKEEPING
|
|
bool
|
|
default n
|
|
|
|
config CLOCK_TIMEKEEPING
|
|
bool "Support timekeeping algorithms"
|
|
default n
|
|
depends on ARCH_HAVE_TIMEKEEPING
|
|
---help---
|
|
CLOCK_TIMEKEEPING enables experimental time management algorithms.
|
|
|
|
config JULIAN_TIME
|
|
bool "Enables Julian time conversions"
|
|
default n
|
|
---help---
|
|
Enables Julian time conversions
|
|
|
|
config START_YEAR
|
|
int "Start year"
|
|
default 2018
|
|
range 1970 2106
|
|
---help---
|
|
NuttX uses an unsigned 32-bit integer for time_t which provides a
|
|
range from 1970 to 2106.
|
|
|
|
config START_MONTH
|
|
int "Start month"
|
|
default 1
|
|
range 1 12
|
|
|
|
config START_DAY
|
|
int "Start day"
|
|
default 1
|
|
range 1 31
|
|
|
|
config PREALLOC_TIMERS
|
|
int "Number of pre-allocated POSIX timers"
|
|
default 4 if DEFAULT_SMALL
|
|
default 8 if !DEFAULT_SMALL
|
|
depends on !DISABLE_POSIX_TIMERS
|
|
---help---
|
|
The number of pre-allocated POSIX timer structures. The system manages a
|
|
pool of preallocated timer structures to minimize dynamic allocations. Set to
|
|
zero for all dynamic allocations.
|
|
|
|
config PERF_OVERFLOW_CORRECTION
|
|
bool "Compensate perf count overflow"
|
|
depends on SYSTEM_TIME64 && (ALARM_ARCH || TIMER_ARCH || ARCH_PERF_EVENTS)
|
|
default n
|
|
---help---
|
|
If this option is enabled, then the perf event will be enabled
|
|
by default.
|
|
When enabled, it will always return an increasing count value to
|
|
avoid overflow on 32-bit platforms.
|
|
|
|
endmenu # Clocks and Timers
|
|
|
|
menu "Tasks and Scheduling"
|
|
|
|
config SPINLOCK
|
|
bool "Support Spinlocks"
|
|
default n
|
|
---help---
|
|
Enables support for spinlocks. Spinlocks are used primarily for
|
|
synchronization in SMP configurations but are available for general
|
|
synchronization between CPUs. Use in a single CPU configuration would
|
|
most likely be fatal. Note, however, that this does not depend on
|
|
CONFIG_ARCH_HAVE_MULTICPU. This permits the use of spinlocks in
|
|
other novel architectures.
|
|
|
|
if SPINLOCK
|
|
|
|
config TICKET_SPINLOCK
|
|
bool "Use ticket Spinlocks"
|
|
default n
|
|
---help---
|
|
Use ticket spinlock algorithm.
|
|
|
|
config RW_SPINLOCK
|
|
bool "Support read-write Spinlocks"
|
|
default y
|
|
---help---
|
|
Spinlocks are spilit into read and write lock.
|
|
Reader can take read lock simultaneously and only one writer
|
|
can take write lock.
|
|
|
|
endif # SPINLOCK
|
|
|
|
config IRQCHAIN
|
|
bool "Enable multi handler sharing a IRQ"
|
|
default n
|
|
---help---
|
|
Enable support for IRQCHAIN.
|
|
|
|
if IRQCHAIN
|
|
|
|
config PREALLOC_IRQCHAIN
|
|
int "Number of pre-allocated irq chains"
|
|
default 4 if DEFAULT_SMALL
|
|
default 8 if !DEFAULT_SMALL
|
|
---help---
|
|
The number of pre-allocated irq chain structures. The system manages
|
|
a pool of preallocated irq chain structures to minimize dynamic
|
|
allocations. You will, however, get better performance and memory
|
|
usage if this value is tuned to minimize such allocations.
|
|
|
|
endif # IRQCHAIN
|
|
|
|
config IRQ_NWORKS
|
|
int "Max num of active irq wqueue"
|
|
default 8
|
|
---help---
|
|
The max num of active irq wqueue.
|
|
|
|
config IRQ_WORK_STACKSIZE
|
|
int "The default stack size for isr wqueue"
|
|
default DEFAULT_TASK_STACKSIZE
|
|
---help---
|
|
The default stack size for isr wqueue.
|
|
|
|
config IRQCOUNT
|
|
bool
|
|
default n
|
|
|
|
config SMP
|
|
bool "Symmetric Multi-Processing (SMP)"
|
|
default n
|
|
depends on ARCH_HAVE_MULTICPU
|
|
depends on ARCH_HAVE_TESTSET
|
|
depends on ARCH_INTERRUPTSTACK != 0
|
|
select SPINLOCK
|
|
select IRQCOUNT
|
|
---help---
|
|
Enables support for Symmetric Multi-Processing (SMP) on a multi-CPU
|
|
platform.
|
|
|
|
N.B. SMP mode requires the use of ARCH_INTERRUPTSTACK:
|
|
|
|
CPU0 thread0 -> IRQ enter -> add thread0 to block_list -> IRQ leave(crash)
|
|
||
|
|
/\
|
|
/ \
|
|
CPU1 thread1 -> block_task -> take thread0 from block_list -> run thread0
|
|
|
|
CPU0 IRQ handler use thread0's stack, but thread0 may switch to CPU1, that
|
|
will caused IRQ handler stack corruption.
|
|
|
|
if SMP
|
|
|
|
config SMP_NCPUS
|
|
int "Number of CPUs"
|
|
default 4
|
|
range 1 32
|
|
---help---
|
|
This value identifies the number of CPUs supported by the processor
|
|
that will be used for SMP.
|
|
|
|
If CONFIG_DEBUG_FEATURES is enabled, then the value one is permitted
|
|
for CONFIG_SMP_NCPUS. This is not normally a valid setting for an
|
|
SMP configuration. However, running the SMP logic in a single CPU
|
|
configuration is useful during certain testing.
|
|
|
|
config SMP_DEFAULT_CPUSET
|
|
hex "Default CPU bit set"
|
|
default 0xffffffff
|
|
---help---
|
|
Set the Default CPU bits. The way to use the unset CPU is to call the
|
|
sched_setaffinity function to bind a task to the CPU. bit0 means CPU0.
|
|
|
|
endif # SMP
|
|
|
|
choice
|
|
prompt "Initialization Task"
|
|
default INIT_ENTRY if !BUILD_KERNEL
|
|
default INIT_FILE if !BINFMT_DISABLE
|
|
default INIT_NONE if BINFMT_DISABLE
|
|
|
|
config INIT_NONE
|
|
bool "None"
|
|
|
|
config INIT_ENTRY
|
|
bool "Via application entry"
|
|
depends on !BUILD_KERNEL
|
|
|
|
config INIT_FILE
|
|
bool "Via executable file"
|
|
depends on !BINFMT_DISABLE
|
|
|
|
endchoice # Initialization task
|
|
|
|
config INIT_ARGS
|
|
string "Application argument list"
|
|
depends on !INIT_NONE
|
|
---help---
|
|
The argument list for user applications. e.g.:
|
|
"\"arg1\",\"arg2\",\"arg3\""
|
|
|
|
config INIT_STACKSIZE
|
|
int "Main thread stack size"
|
|
default DEFAULT_TASK_STACKSIZE
|
|
---help---
|
|
The size of the stack to allocate for the user initialization thread
|
|
that is started as soon as the OS completes its initialization.
|
|
|
|
config INIT_PRIORITY
|
|
int "init thread priority"
|
|
default 100
|
|
---help---
|
|
The priority of the user initialization thread.
|
|
|
|
if INIT_ENTRY
|
|
config INIT_ENTRYPOINT
|
|
string "Application entry point"
|
|
default "main"
|
|
---help---
|
|
The name of the entry point for user applications. For the example
|
|
applications this is of the form 'app_main' where 'app' is the application
|
|
name. If not defined, INIT_ENTRYPOINT defaults to "main".
|
|
|
|
Note that main must take "argc" and "argv" arguments:
|
|
|
|
int main(int argc, FAR char *argv[])
|
|
|
|
Otherwise, if using a signature such as "int main(void)" a compilation
|
|
error will result:
|
|
|
|
> $ make
|
|
> CC: CustomHello.c <command-line>: error: conflicting types for
|
|
> 'custom_hello_main'
|
|
> CustomHello.c:3:5: note: in expansion of macro 'main'
|
|
> 3 | int main(void)
|
|
> | ^~~~
|
|
|
|
config INIT_ENTRYNAME
|
|
string "Application entry name"
|
|
default INIT_ENTRYPOINT
|
|
|
|
endif # INIT_ENTRY
|
|
|
|
if INIT_FILE
|
|
|
|
config INIT_FILEPATH
|
|
string "Application initialization path"
|
|
default "/bin/init"
|
|
---help---
|
|
The name of the entry point for user applications. For the example
|
|
applications this is of the form 'app_main' where 'app' is the application
|
|
name. If not defined, INIT_ENTRYPOINT defaults to "main".
|
|
|
|
config INIT_SYMTAB
|
|
string "Symbol table"
|
|
default "NULL" if !EXECFUNCS_HAVE_SYMTAB
|
|
default EXECFUNCS_SYMTAB_ARRAY if EXECFUNCS_HAVE_SYMTAB
|
|
depends on BUILD_FLAT
|
|
---help---
|
|
The name of other global array that holds the exported symbol table.
|
|
The special string "NULL" may be provided if there is no symbol
|
|
table. Quotation marks will be stripped when config.h is generated.
|
|
|
|
NOTE: This setting cannot be used in protected or kernel builds.
|
|
Any kernel mode symbols tables would not be usable for resolving
|
|
symbols in user mode executables.
|
|
|
|
config INIT_NEXPORTS
|
|
string "Symbol table size"
|
|
default "0" if !EXECFUNCS_HAVE_SYMTAB
|
|
default EXECFUNCS_NSYMBOLS_VAR if EXECFUNCS_HAVE_SYMTAB
|
|
depends on BUILD_FLAT
|
|
---help---
|
|
The size of the symbol table. NOTE that is is logically a numeric
|
|
value but is represent by a string. That allows you to put
|
|
sizeof(something) or a macro or a global variable name for the
|
|
symbol table size. Quotation marks will be stripped when config.h
|
|
is generated.
|
|
|
|
NOTE: This setting cannot be used in protected or kernel builds.
|
|
Any kernel mode symbols tables would not be usable for resolving
|
|
symbols in user mode executables.
|
|
|
|
menuconfig INIT_MOUNT
|
|
bool "Auto-mount init file system"
|
|
default n
|
|
depends on !DISABLE_MOUNTPOINT
|
|
---help---
|
|
In order to use the the initial startup program when CONFIG_INIT_FILEPATH
|
|
is provided, it is necessary to mount the initial file system that
|
|
provides init program. Normally this mount is done in the board-specific
|
|
initialization logic. However, if the mount is very simple, it can be
|
|
performed by the OS bring-up logic itself by selecting this option.
|
|
|
|
if INIT_MOUNT
|
|
|
|
config INIT_MOUNT_SOURCE
|
|
string "The block device to mount"
|
|
default "/dev/ram0"
|
|
|
|
config INIT_MOUNT_TARGET
|
|
string "Path to the mounted file system"
|
|
default "/bin"
|
|
|
|
config INIT_MOUNT_FSTYPE
|
|
string "The file system type to mount"
|
|
default "romfs"
|
|
|
|
config INIT_MOUNT_FLAGS
|
|
hex "Flags passed to mount"
|
|
default 0
|
|
|
|
config INIT_MOUNT_DATA
|
|
string "Additional data passed to mount"
|
|
default ""
|
|
|
|
endif # INIT_MOUNT
|
|
endif # INIT_FILE
|
|
|
|
menuconfig ETC_ROMFS
|
|
bool "Auto-mount etc baked-in ROMFS image"
|
|
default n
|
|
depends on !DISABLE_MOUNTPOINT && FS_ROMFS
|
|
---help---
|
|
Mount a ROMFS filesystem at /etc and provide a system init
|
|
script at /etc/init.d/rc.sysinit and a startup script
|
|
at /etc/init.d/rcS. The default system init script will mount
|
|
a FAT FS RAMDISK at /tmp but the logic is easily extensible.
|
|
|
|
if ETC_ROMFS
|
|
|
|
config ETC_CROMFS
|
|
bool "Support CROMFS (compressed) start-up script"
|
|
default n
|
|
depends on FS_CROMFS
|
|
---help---
|
|
Mount a CROMFS filesystem at /etc and provide a compressed system
|
|
init script at /etc/init.d/rc.sysinit and a startup script
|
|
at /etc/init.d/rcS.
|
|
|
|
config ETC_ROMFSMOUNTPT
|
|
string "Mountpoint of the etc romfs image"
|
|
default "/etc"
|
|
|
|
config ETC_ROMFSDEVNO
|
|
int "ROMFS block device minor number"
|
|
default 0
|
|
---help---
|
|
This is the minor number of the ROMFS block device. The default is
|
|
'0' corresponding to /dev/ram0.
|
|
|
|
config ETC_ROMFSSECTSIZE
|
|
int "ROMFS sector size"
|
|
default 64
|
|
---help---
|
|
This is the sector size to use with the ROMFS volume. Since the
|
|
default volume is very small, this defaults to 64 but should be
|
|
increased if the ROMFS volume were to be become large. Any value
|
|
selected must be a power of 2.
|
|
|
|
config ETC_FATDEVNO
|
|
int "FAT block device minor number"
|
|
default 1
|
|
depends on FS_FAT
|
|
---help---
|
|
When the default rcS file used when ETC_ROMFS is selected, it
|
|
will mount a FAT FS under /tmp. This is the minor number of the FAT
|
|
FS block device. The default is '1' corresponding to /dev/ram1.
|
|
|
|
config ETC_FATSECTSIZE
|
|
int "FAT sector size"
|
|
default 512
|
|
depends on FS_FAT
|
|
---help---
|
|
When the default rcS file used when ETC_ROMFS is selected, it
|
|
will mount a FAT FS under /tmp. This is the sector size use with the
|
|
FAT FS. Default is 512.
|
|
|
|
config ETC_FATNSECTORS
|
|
int "FAT number of sectors"
|
|
default 1024
|
|
depends on FS_FAT
|
|
---help---
|
|
When the default rcS file used when ETC_ROMFS is selected, it
|
|
will mount a FAT FS under /tmp. This is the number of sectors to use
|
|
with the FAT FS. Default is 1024. The amount of memory used by the
|
|
FAT FS will be ETC_FATSECTSIZE * ETC_FATNSECTORS bytes.
|
|
|
|
config ETC_FATMOUNTPT
|
|
string "FAT mount point"
|
|
default "/tmp"
|
|
depends on FS_FAT
|
|
---help---
|
|
When the default rcS file used when ETC_ROMFS is selected, it
|
|
will mount a FAT FS under /tmp. This is the location where the FAT
|
|
FS will be mounted. Default is "/tmp".
|
|
|
|
endif # ETC_ROMFS
|
|
|
|
config RR_INTERVAL
|
|
int "Round robin timeslice (MSEC)"
|
|
default 0
|
|
---help---
|
|
The round robin timeslice will be set this number of milliseconds;
|
|
Round robin scheduling (SCHED_RR) is enabled by setting this
|
|
interval to a positive, non-zero value.
|
|
|
|
config SCHED_SPORADIC
|
|
bool "Support sporadic scheduling"
|
|
default n
|
|
select SCHED_SUSPENDSCHEDULER
|
|
select SCHED_RESUMESCHEDULER
|
|
---help---
|
|
Build in additional logic to support sporadic scheduling
|
|
(SCHED_SPORADIC).
|
|
|
|
if SCHED_SPORADIC
|
|
|
|
config SCHED_SPORADIC_MAXREPL
|
|
int "Maximum number of replenishments"
|
|
default 3
|
|
range 1 255
|
|
---help---
|
|
Controls the size of allocated replenishment structures and, hence,
|
|
also limits the maximum number of replenishments.
|
|
|
|
config SPORADIC_INSTRUMENTATION
|
|
bool "Sporadic scheduler monitor hooks"
|
|
default n
|
|
---help---
|
|
Enables instrumentation in the sporadic scheduler to monitor
|
|
scheduler behavior. If enabled, then the board-specific logic must
|
|
provide the following functions:
|
|
|
|
void arch_sporadic_start(FAR struct tcb_s *tcb);
|
|
void arch_sporadic_lowpriority(FAR struct tcb_s *tcb);
|
|
void arch_sporadic_suspend(FAR struct tcb_s *tcb);
|
|
void arch_sporadic_resume(FAR struct tcb_s *tcb);
|
|
|
|
endif # SCHED_SPORADIC
|
|
|
|
config TASK_NAME_SIZE
|
|
int "Maximum task name size"
|
|
default 31
|
|
---help---
|
|
Specifies the maximum size of a task name to save in the TCB.
|
|
Useful if scheduler instrumentation is selected. Set to zero to
|
|
disable. Excludes the NUL terminator; the actual allocated size
|
|
will be TASK_NAME_SIZE + 1. The default of 31 then results in
|
|
a align-able 32-byte allocation.
|
|
|
|
config SCHED_HAVE_PARENT
|
|
bool "Support parent/child task relationships"
|
|
default n
|
|
---help---
|
|
Remember the ID of the parent task when a new child task is
|
|
created. This support enables some additional features (such as
|
|
SIGCHLD) and modifies the behavior of other interfaces. For
|
|
example, it makes waitpid() more standards complete by restricting
|
|
the waited-for tasks to the children of the caller. Default:
|
|
disabled.
|
|
|
|
config SCHED_CHILD_STATUS
|
|
bool "Retain child exit status"
|
|
default n
|
|
depends on SCHED_HAVE_PARENT
|
|
---help---
|
|
If this option is selected, then the exit status of the child task
|
|
will be retained after the child task exits. This option should be
|
|
selected if you require knowledge of a child process's exit status.
|
|
Without this setting, wait(), waitpid() or waitid() may fail. For
|
|
example, if you do:
|
|
|
|
1) Start child task
|
|
2) Wait for exit status (using wait(), waitpid(), or waitid()).
|
|
|
|
This can fail because the child task may run to completion before
|
|
the wait begins. There is a non-standard work-around in this case:
|
|
The above sequence will work if you disable pre-emption using
|
|
sched_lock() prior to starting the child task, then re-enable pre-
|
|
emption with sched_unlock() after the wait completes. This works
|
|
because the child task is not permitted to run until the wait is in
|
|
place.
|
|
|
|
The standard solution would be to enable SCHED_CHILD_STATUS. In
|
|
this case the exit status of the child task is retained after the
|
|
child exits and the wait will successful obtain the child task's
|
|
exit status whether it is called before the child task exits or not.
|
|
|
|
Warning: If you enable this feature, then your application must
|
|
either (1) take responsibility for reaping the child status with wait(),
|
|
waitpid(), or waitid(), or (2) suppress retention of child status.
|
|
If you do not reap the child status, then you have a memory leak and
|
|
your system will eventually fail.
|
|
|
|
Retention of child status can be suppressed on the parent using logic like:
|
|
|
|
struct sigaction sa;
|
|
|
|
sa.sa_handler = SIG_IGN;
|
|
sa.sa_flags = SA_NOCLDWAIT;
|
|
int ret = sigaction(SIGCHLD, &sa, NULL);
|
|
|
|
if SCHED_CHILD_STATUS
|
|
|
|
config PREALLOC_CHILDSTATUS
|
|
int "Number of pre-allocated child status"
|
|
default 0
|
|
---help---
|
|
To prevent runaway child status allocations and to improve
|
|
allocation performance, child task exit status structures are pre-
|
|
allocated when the system boots. This setting determines the number
|
|
of child status structures that will be pre-allocated.
|
|
|
|
However, the number of child status structures may need to be
|
|
significantly larger because this number includes the maximum number
|
|
of tasks that are running PLUS the number of tasks that have exit'ed
|
|
without having their exit status reaped (via wait(), waitid(), or
|
|
waitpid()).
|
|
|
|
Obviously, if tasks spawn children indefinitely and never have the
|
|
exit status reaped, then you may have a memory leak! If you enable
|
|
the SCHED_CHILD_STATUS feature, then your application must take
|
|
responsibility for either (1) reaping the child status with wait(),
|
|
waitpid(), or waitid() or it must (2) suppress retention of child
|
|
status. Otherwise, your system will eventually fail.
|
|
|
|
Retention of child status can be suppressed on the parent using logic like:
|
|
|
|
struct sigaction sa;
|
|
|
|
sa.sa_handler = SIG_IGN;
|
|
sa.sa_flags = SA_NOCLDWAIT;
|
|
int ret = sigaction(SIGCHLD, &sa, NULL);
|
|
|
|
config DEBUG_CHILDSTATUS
|
|
bool "Enable Child Status Debug Output"
|
|
default n
|
|
depends on SCHED_CHILD_STATUS && DEBUG_FEATURES
|
|
---help---
|
|
Very detailed... I am sure that you do not want this.
|
|
|
|
endif # SCHED_CHILD_STATUS
|
|
|
|
config SCHED_WAITPID
|
|
bool "Enable waitpid() API"
|
|
default n
|
|
depends on SCHED_HAVE_PARENT || !BUILD_KERNEL
|
|
---help---
|
|
Enables the waitpid() interface in a default, non-standard mode
|
|
(non-standard in the sense that the waited for PID need not be child
|
|
of the caller). If SCHED_HAVE_PARENT is also defined, then this
|
|
setting will modify the behavior or waitpid() (making more spec
|
|
compliant) and will enable the waitid() and wait() interfaces as
|
|
well. Note that SCHED_HAVE_PARENT must be defined in BUILD_KERNEL if
|
|
SCHED_WAITPID is needed.
|
|
|
|
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.
|
|
|
|
config SCHED_DUMP_ON_EXIT
|
|
bool "Dump all tasks state on exit"
|
|
default n
|
|
---help---
|
|
Dump all tasks state on exit()
|
|
|
|
config SCHED_USER_IDENTITY
|
|
bool "Support per-task User Identity"
|
|
default n
|
|
---help---
|
|
This selection enables functionality of getuid(), setuid(), getgid(),
|
|
setgid(). If this option is not selected, then stub, root-only
|
|
versions of these interfaces are available. When selected, these
|
|
interfaces will associate a UID and/or GID with each task group.
|
|
Those can then be managed using the interfaces. Child tasks will
|
|
inherit the UID and GID of its parent.
|
|
|
|
config SCHED_THREAD_LOCAL
|
|
bool "Support __thread/thread_local keyword"
|
|
default n
|
|
depends on ARCH_HAVE_THREAD_LOCAL
|
|
---help---
|
|
This option enables architecture-specific TLS support (__thread/thread_local keyword)
|
|
Note: Toolchain must be compiled with '--enable-tls' enabled
|
|
|
|
endmenu # Tasks and Scheduling
|
|
|
|
menu "Pthread Options"
|
|
depends on !DISABLE_PTHREAD
|
|
|
|
config PTHREAD_MUTEX_TYPES
|
|
bool "Enable mutex types"
|
|
default n
|
|
---help---
|
|
Set to enable support for recursive and errorcheck mutexes. Enables
|
|
pthread_mutexattr_settype().
|
|
|
|
choice
|
|
prompt "pthread mutex robustness"
|
|
default PTHREAD_MUTEX_ROBUST if !DEFAULT_SMALL
|
|
default PTHREAD_MUTEX_UNSAFE if DEFAULT_SMALL
|
|
|
|
config PTHREAD_MUTEX_ROBUST
|
|
bool "Robust mutexes"
|
|
---help---
|
|
Support only the robust form of the NORMAL mutex.
|
|
|
|
config PTHREAD_MUTEX_UNSAFE
|
|
bool "Traditional unsafe mutexes"
|
|
---help---
|
|
Support only the traditional non-robust form of the NORMAL mutex.
|
|
You should select this option only for backward compatibility with
|
|
software you may be porting or, perhaps, if you are trying to minimize
|
|
footprint.
|
|
|
|
config PTHREAD_MUTEX_BOTH
|
|
bool "Both robust and unsafe mutexes"
|
|
---help---
|
|
Support both forms of NORMAL mutexes.
|
|
|
|
endchoice # pthread mutex robustness
|
|
|
|
choice
|
|
prompt "Default NORMAL mutex robustness"
|
|
default PTHREAD_MUTEX_DEFAULT_ROBUST
|
|
depends on PTHREAD_MUTEX_BOTH
|
|
|
|
config PTHREAD_MUTEX_DEFAULT_ROBUST
|
|
bool "Robust default"
|
|
---help---
|
|
The default is robust NORMAL mutexes (non-standard)
|
|
|
|
config PTHREAD_MUTEX_DEFAULT_UNSAFE
|
|
bool "Unsafe default"
|
|
---help---
|
|
The default is traditional unsafe NORMAL mutexes (standard)
|
|
|
|
endchoice # Default NORMAL mutex robustness
|
|
|
|
choice
|
|
prompt "Default pthread mutex protocol"
|
|
default PTHREAD_MUTEX_DEFAULT_PRIO_NONE
|
|
|
|
config PTHREAD_MUTEX_DEFAULT_PRIO_NONE
|
|
bool "PTHREAD_PRIO_NONE default"
|
|
---help---
|
|
By default, pthread mutexes utilize PTHREAD_PRIO_NONE protocol (standard).
|
|
|
|
config PTHREAD_MUTEX_DEFAULT_PRIO_INHERIT
|
|
bool "PTHREAD_PRIO_INHERIT default"
|
|
depends on PRIORITY_INHERITANCE
|
|
---help---
|
|
By default, pthread mutexes utilize PTHREAD_PRIO_INHERIT protocol
|
|
(POSIX non-standard but a reasonable choice for most real-time systems).
|
|
|
|
endchoice # Default pthread mutex protocol
|
|
|
|
config CANCELLATION_POINTS
|
|
bool "Cancellation points"
|
|
default n
|
|
---help---
|
|
Enable POSIX cancellation points for pthread_cancel(). If selected,
|
|
cancellation points will also used with the task_delete() API even if
|
|
pthreads are not enabled.
|
|
|
|
endmenu # Pthread Options
|
|
|
|
menu "Performance Monitoring"
|
|
|
|
config SCHED_SUSPENDSCHEDULER
|
|
bool
|
|
default n
|
|
|
|
config SCHED_RESUMESCHEDULER
|
|
bool
|
|
default n
|
|
|
|
config SCHED_IRQMONITOR
|
|
bool "Enable IRQ monitoring"
|
|
default n
|
|
depends on FS_PROCFS
|
|
---help---
|
|
Enabling counting of interrupts from all interrupt sources. These
|
|
counts will be available in the mounted procfs file systems at the
|
|
top-level file, "irqs".
|
|
|
|
config SCHED_CRITMONITOR
|
|
bool "Enable Critical Section monitoring"
|
|
default n
|
|
depends on FS_PROCFS
|
|
select SCHED_SUSPENDSCHEDULER
|
|
select SCHED_RESUMESCHEDULER
|
|
select IRQCOUNT
|
|
---help---
|
|
Enables logic that monitors the duration of time that a thread keeps
|
|
interrupts or pre-emption disabled. These global locks can have
|
|
negative consequences to real time performance: Disabling interrupts
|
|
adds jitter in the time when an interrupt request is asserted until
|
|
the hardware can respond with the interrupt. Disabling pre-emption
|
|
adds jitter in the time from when the event is posted in the
|
|
interrupt handler until the task that responds to the event can run.
|
|
|
|
if SCHED_CRITMONITOR
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_THREAD
|
|
int "THREAD max execution time"
|
|
default 0
|
|
---help---
|
|
Thread execution time should be smaller than
|
|
SCHED_CRITMONITOR_MAXTIME_THREAD, or system will give a warning.
|
|
For debugging system latency, 0 means disabled.
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_WQUEUE
|
|
int "WORK queue max execution time"
|
|
default -1
|
|
---help---
|
|
Worker execution time should be smaller than
|
|
SCHED_CRITMONITOR_MAXTIME_WQUEUE, or system will give a warning.
|
|
For debugging system latency, 0 means disabled.
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_PREEMPTION
|
|
int "Pre-emption (sched_lock) max holding time"
|
|
default SCHED_CRITMONITOR_MAXTIME_WQUEUE
|
|
---help---
|
|
Pre-emption holding time should be smaller than
|
|
SCHED_CRITMONITOR_MAXTIME_PREEMPTION, or system will give a warning.
|
|
For debugging system latency, 0 means disabled.
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_CSECTION
|
|
int "Csection (enter_critical_section) max holding time"
|
|
default SCHED_CRITMONITOR_MAXTIME_PREEMPTION
|
|
---help---
|
|
Csection holding time should be smaller than
|
|
SCHED_CRITMONITOR_MAXTIME_CSECTION, or system will give a warning.
|
|
For debugging system latency, 0 means disabled.
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_IRQ
|
|
int "IRQ max execution time"
|
|
default SCHED_CRITMONITOR_MAXTIME_CSECTION
|
|
---help---
|
|
IRQ handler execution time should be smaller than
|
|
SCHED_CRITMONITOR_MAXTIME_IRQ, or system will give a warning.
|
|
For debugging system latency, 0 means disabled.
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_WDOG
|
|
int "WDOG callback max execution time"
|
|
default SCHED_CRITMONITOR_MAXTIME_IRQ
|
|
---help---
|
|
Wdog callback execution time should be smaller than
|
|
SCHED_CRITMONITOR_MAXTIME_WDOG, or system will give a warning.
|
|
For debugging system latency, 0 means disabled.
|
|
|
|
endif # SCHED_CRITMONITOR
|
|
|
|
config SCHED_CRITMONITOR_MAXTIME_PANIC
|
|
bool "Monitor timeout panic"
|
|
depends on \
|
|
SCHED_CRITMONITOR_MAXTIME_THREAD > 0 || \
|
|
SCHED_CRITMONITOR_MAXTIME_WDOG > 0 || \
|
|
SCHED_CRITMONITOR_MAXTIME_WQUEUE > 0 || \
|
|
SCHED_CRITMONITOR_MAXTIME_PREEMPTION > 0 || \
|
|
SCHED_CRITMONITOR_MAXTIME_CSECTION > 0 || \
|
|
SCHED_CRITMONITOR_MAXTIME_IRQ > 0
|
|
default n
|
|
---help---
|
|
If this option is enabled, a panic will be triggered when
|
|
IRQ/WQUEUE/PREEMPTION execution time exceeds SCHED_CRITMONITOR_MAXTIME_xxx
|
|
|
|
choice
|
|
prompt "Select CPU load clock source"
|
|
default SCHED_CPULOAD_NONE
|
|
---help---
|
|
If this option is selected, the timer interrupt handler will monitor
|
|
if the system is IDLE or busy at the time of that the timer interrupt
|
|
occurs. This is a very coarse measurement, but over a period of time,
|
|
it can very accurately determine the percentage of the time that the
|
|
CPU is IDLE.
|
|
|
|
The statistics collected in this could be used, for example, in the
|
|
PROCFS file system to provide CPU load measurements when read.
|
|
|
|
Note that in tickless mode of operation (SCHED_TICKLESS) there is
|
|
no system timer interrupt and CPU load measurements will not be
|
|
possible unless you provide an alternative clock to drive the
|
|
sampling and select SCHED_CPULOAD_EXTCLK.
|
|
|
|
config SCHED_CPULOAD_NONE
|
|
bool "None CPU load clock source"
|
|
---help---
|
|
If this option is enabled, the system will not support CPU load
|
|
measurement.
|
|
|
|
config SCHED_CPULOAD_SYSCLK
|
|
bool "Use system clock"
|
|
depends on !SCHED_TICKLESS
|
|
---help---
|
|
If this option is enabled, the system clock is used for cpu load
|
|
measurement by default.
|
|
|
|
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 CPU load measurements are determined by sampling the active
|
|
tasks periodically at the occurrence to a timer expiration.
|
|
If tickless is enabled, SYSCLK should not be used. Its error will be
|
|
very large, and using it for analysis will lead to wrong conclusions.
|
|
|
|
config SCHED_CPULOAD_EXTCLK
|
|
bool "Use external clock"
|
|
---help---
|
|
There is a serious issue for the accuracy of measurements if the
|
|
system clock is used, however. NuttX threads are often started at
|
|
the time of the system timer expiration. Others may be stopped at
|
|
the time of the system timer expiration (if round-robin time-slicing
|
|
is enabled). Such thread behavior occurs synchronously with the
|
|
system timer and, hence, is not randomly sampled. As a consequence,
|
|
the CPU load attributed to these threads that run synchronously with
|
|
they system timer may be grossly in error.
|
|
|
|
The solution is to use some other clock that runs at a different
|
|
rate and has timer expirations that are asynchronous with the
|
|
system timer. Then truly accurate load measurements can be
|
|
achieved. This option enables use of such an "external" clock. The
|
|
implementation of the clock must be provided by platform-specific
|
|
logic; that platform-specific logic must call the system function
|
|
nxsched_process_cpuload_ticks() at each timer expiration with interrupts
|
|
disabled.
|
|
|
|
config SCHED_CPULOAD_CRITMONITOR
|
|
bool "Use critical monitor"
|
|
depends on SCHED_CRITMONITOR_MAXTIME_THREAD >= 0
|
|
---help---
|
|
Use the perfcounter in the core of the chip as a counter, no need to
|
|
use an external timer. Need to depend on SCHED_CRITMONITOR.
|
|
When the task is suspended, call nxsched_critmon_cpuload_ticks to count
|
|
the recent running time of the task
|
|
|
|
endchoice
|
|
|
|
if SCHED_CPULOAD_EXTCLK
|
|
|
|
config SCHED_CPULOAD_TICKSPERSEC
|
|
int "External clock rate"
|
|
default 100
|
|
---help---
|
|
If an external clock is used to drive the sampling for the CPU load
|
|
calculations, then this value must be provided. This value provides
|
|
the rate of the external clock interrupts in units of ticks per
|
|
second. The default value of 100 corresponds to a 100Hz clock. NOTE:
|
|
that 100Hz is the default frequency of the system time and, hence,
|
|
the worst possible choice in most cases.
|
|
|
|
choice
|
|
prompt "Select CPU load timer"
|
|
default CPULOAD_ONESHOT
|
|
|
|
config CPULOAD_ONESHOT
|
|
bool "Use Oneshot timer"
|
|
---help---
|
|
Use an MCU-specific oneshot timer as the external clock. The
|
|
oneshot timer must be configured by board specific logic which must
|
|
then call:
|
|
|
|
void nxsched_oneshot_extclk(FAR struct oneshot_lowerhalf_s *lower);
|
|
|
|
To start the CPU load measurement. See include/nuttx/clock.h
|
|
|
|
NOTE that in this configuration, CONFIG_SCHED_CPULOAD_TICKSPERSEC is
|
|
the sample rate that will be accomplished by programming the oneshot
|
|
time repeatedly. If CPULOAD_ONESHOT_ENTROPY is also selected, then
|
|
the underly frequency driving the oneshot timer must be
|
|
significantly faster than CONFIG_SCHED_CPULOAD_TICKSPERSE to permit
|
|
precise modulation the sample periods.
|
|
|
|
config CPULOAD_PERIOD
|
|
bool "Use Period timer"
|
|
---help---
|
|
Use an MCU-specific period timer as the external clock. The
|
|
period timer must be configured by board specific logic which must
|
|
then call:
|
|
|
|
void nxsched_period_extclk(FAR struct timer_lowerhalf_s *lower);
|
|
|
|
To start the CPU load measurement. See include/nuttx/clock.h
|
|
|
|
NOTE that in this configuration, CONFIG_SCHED_CPULOAD_TICKSPERSEC is
|
|
the sample rate that will be accomplished by programming the period
|
|
time.
|
|
|
|
endchoice
|
|
|
|
config CPULOAD_ENTROPY
|
|
int "Bits of entropy"
|
|
default 6
|
|
range 0 30
|
|
---help---
|
|
This is the number of bits of entropy that will be applied. The
|
|
oneshot will be set to this interval:
|
|
|
|
CPULOAD_ONESHOT_NOMINAL - (CPULOAD_ONESHOT_ENTROPY / 2) +
|
|
error + nrand(CPULOAD_ONESHOT_ENTROPY)
|
|
|
|
Where
|
|
|
|
CPULOAD_ONESHOT_NOMINAL is the nominal sample interval implied
|
|
by CONFIG_SCHED_CPULOAD_TICKSPERSEC in units of microseconds.
|
|
CPULOAD_ONESHOT_ENTROPY is (1 << CONFIG_CPULOAD_ENTROPY),
|
|
and 'error' is an error value that is retained from interval to
|
|
interval so that although individual intervals are randomized,
|
|
the average will still be CONFIG_SCHED_CPULOAD_TICKSPERSEC.
|
|
|
|
This special value of zero disables entropy.
|
|
|
|
endif # SCHED_CPULOAD_EXTCLK
|
|
|
|
config SCHED_CPULOAD_TIMECONSTANT
|
|
int "CPU load time constant"
|
|
depends on !SCHED_CPULOAD_NONE
|
|
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.
|
|
|
|
menuconfig SCHED_INSTRUMENTATION
|
|
bool "System performance monitor hooks"
|
|
default n
|
|
select SCHED_SUSPENDSCHEDULER
|
|
select SCHED_RESUMESCHEDULER
|
|
---help---
|
|
Enables instrumentation in scheduler to monitor system performance.
|
|
If enabled, then the board-specific logic must provide the following
|
|
functions (see include/sched.h):
|
|
|
|
void sched_note_start(FAR struct tcb_s *tcb);
|
|
void sched_note_stop(FAR struct tcb_s *tcb);
|
|
|
|
If CONFIG_SMP is enabled, then these additional interfaces are
|
|
expected:
|
|
|
|
void sched_note_cpu_start(FAR struct tcb_s *tcb, int cpu);
|
|
void sched_note_cpu_started(FAR struct tcb_s *tcb);
|
|
|
|
if SCHED_INSTRUMENTATION
|
|
|
|
config SCHED_INSTRUMENTATION_CPUSET
|
|
hex "CPU bit set"
|
|
default 0xffff
|
|
depends on SMP && SCHED_INSTRUMENTATION_FILTER
|
|
---help---
|
|
Monitor only CPUs in the bitset. Bit 0=CPU0, Bit1=CPU1, etc.
|
|
|
|
config SCHED_INSTRUMENTATION_FILTER
|
|
bool "Instrumentation filter"
|
|
default n
|
|
---help---
|
|
Enables the filter logic for the instrumentation. If this option
|
|
is enabled, the instrumentation data passed to sched_note_add()
|
|
can be filtered by syscall and IRQ number.
|
|
The filter logic can be configured by sched_note_filter APIs defined in
|
|
include/nuttx/sched_note.h.
|
|
|
|
config SCHED_INSTRUMENTATION_FILTER_DEFAULT_MODE
|
|
hex "Default instrumentation filter mode"
|
|
depends on SCHED_INSTRUMENTATION_FILTER
|
|
default 0x3f
|
|
---help---
|
|
Default mode of the instrumentation filter logic.
|
|
Bit 0 = Enable instrumentation
|
|
Bit 1 = Enable switch instrumentation
|
|
Bit 2 = Enable syscall instrumentation
|
|
Bit 3 = Enable IRQ instrumentation
|
|
Bit 4 = Enable dump instrumentation
|
|
Bit 5 = Enable collecting syscall arguments
|
|
|
|
config SCHED_INSTRUMENTATION_SWITCH
|
|
bool "Use note switch for instrumentation"
|
|
default n
|
|
---help---
|
|
Use note switch for instrumentation.
|
|
|
|
void sched_note_suspend(FAR struct tcb_s *tcb);
|
|
void sched_note_resume(FAR struct tcb_s *tcb);
|
|
|
|
If CONFIG_SMP is enabled, then these additional interfaces are
|
|
expected:
|
|
|
|
void sched_note_cpu_pause(FAR struct tcb_s *tcb, int cpu);
|
|
void sched_note_cpu_paused(FAR struct tcb_s *tcb);
|
|
void sched_note_cpu_resume(FAR struct tcb_s *tcb, int cpu);
|
|
void sched_note_cpu_resumed(FAR struct tcb_s *tcb);
|
|
|
|
NOTE: These are internal OS interfaces and are called at very
|
|
critical locations in the OS. There is very little that can be
|
|
done in these interfaces. For example, normal devices may not be
|
|
used; syslog output cannot be performed.
|
|
|
|
config SCHED_INSTRUMENTATION_PREEMPTION
|
|
bool "Preemption monitor hooks"
|
|
default n
|
|
---help---
|
|
Enables additional hooks for changes to pre-emption state. Board-
|
|
specific logic must provide this additional logic.
|
|
|
|
void sched_note_premption(FAR struct tcb_s *tcb, bool state);
|
|
|
|
config SCHED_INSTRUMENTATION_CSECTION
|
|
bool "Critical section monitor hooks"
|
|
default n
|
|
select IRQCOUNT
|
|
---help---
|
|
Enables additional hooks for entry and exit from critical sections.
|
|
Interrupts are disabled while within a critical section. Board-
|
|
specific logic must provide this additional logic.
|
|
|
|
void sched_note_csection(FAR struct tcb_s *tcb, bool state);
|
|
|
|
config SCHED_INSTRUMENTATION_SPINLOCKS
|
|
bool "Spinlock monitor hooks"
|
|
default n
|
|
---help---
|
|
Enables additional hooks for spinlock state. Board-specific logic
|
|
must provide this additional logic.
|
|
|
|
void sched_note_spinlock(FAR struct tcb_s *tcb, FAR volatile spinlock_t *spinlock, int type)
|
|
|
|
config SCHED_INSTRUMENTATION_SYSCALL
|
|
bool "System call monitor hooks"
|
|
default n
|
|
depends on ARCH_HAVE_SYSCALL_HOOKS
|
|
---help---
|
|
Enables additional hooks for entry and exit from system call.
|
|
Board-specific logic must provide this additional logic.
|
|
|
|
void sched_note_syscall_enter(int nr, int argc, ...);
|
|
void sched_note_syscall_leave(int nr, uintptr_t result);
|
|
|
|
config SCHED_INSTRUMENTATION_IRQHANDLER
|
|
bool "Interrupt handler monitor hooks"
|
|
default n
|
|
---help---
|
|
Enables additional hooks for interrupt handler. Board-specific logic
|
|
must provide this additional logic.
|
|
|
|
void sched_note_irqhandler(int irq, FAR void *handler, bool enter);
|
|
|
|
config SCHED_INSTRUMENTATION_HEAP
|
|
bool "Heap monitor hooks"
|
|
default n
|
|
---help---
|
|
Enables additional hooks for heap allocation.
|
|
|
|
void sched_note_heap(bool alloc, FAR void* heap, FAR void *mem, size_t size)
|
|
|
|
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, ...) printf_like(1, 2);
|
|
void sched_note_bprintf(uint32_t module, uint8_t event, FAR const char *fmt, ...);
|
|
|
|
config SCHED_INSTRUMENTATION_FUNCTION
|
|
bool "Enable function auto-tracing"
|
|
default n
|
|
---help---
|
|
After enabling this option, you can automatically trace the function instrumentation without adding tracepoint manually.
|
|
This is similar to the Function Trace effect of the linux kernel
|
|
Add CFLAGS += -finstrument-functions to the makefile to track the required modules.
|
|
The following compilation option can exclude files that do not want to be tracked in this module
|
|
CFLAGS += -finstrument-functions-exclude-file-list=xxx
|
|
The following compilation option can exclude functions that do not want to be tracked in this module
|
|
CFLAGS += -finstrument-functions-exclude-function-list=xxx
|
|
For a more detailed description of compilation options,
|
|
refer to the "Program Instrumentation Options" chapter in the gcc documentation
|
|
|
|
endif # SCHED_INSTRUMENTATION
|
|
endmenu # Performance Monitoring
|
|
|
|
menu "System Auto Instrumentation"
|
|
|
|
config SCHED_STACK_RECORD
|
|
int "Maximum stack backtrace to record"
|
|
default 0
|
|
---help---
|
|
Specifies the maximum number of stack backtrace to record in the
|
|
TCB. Useful if scheduler instrumentation is selected. Set to zero
|
|
to disable.Through instrumentation, record the backtrace at
|
|
the deepest point in the stack.
|
|
|
|
endmenu
|
|
|
|
menu "Files and I/O"
|
|
|
|
config DEV_CONSOLE
|
|
bool "Enable /dev/console"
|
|
default y
|
|
---help---
|
|
Set if architecture-specific logic provides /dev/console at boot-up
|
|
time. Enables stdout, stderr, stdin in the start-up application.
|
|
|
|
You need this setting if your console device is ready at boot time.
|
|
For example, if you are using a serial console, then /dev/console
|
|
(aka, /dev/ttyS0) will be available when the application first starts.
|
|
|
|
You must not select DEV_CONSOLE if you console device comes up later
|
|
and is not ready until after the application starts. At this time,
|
|
the only console device that behaves this way is a USB serial console.
|
|
When the application first starts, the USB is (probably) not yet
|
|
connected and /dev/console will not be created until later when the
|
|
host connects to the USB console.
|
|
|
|
config FDCLONE_DISABLE
|
|
bool "Disable cloning of file descriptors"
|
|
default n
|
|
---help---
|
|
Disable cloning of all file descriptors by task_create() when a new
|
|
ask is started. If set, all files/drivers will appear to be closed
|
|
in the new task.
|
|
|
|
config FDCLONE_STDIO
|
|
bool "Disable clone file descriptors without stdio"
|
|
default n
|
|
---help---
|
|
Disable cloning of all but the first three file descriptors (stdin,
|
|
stdout, stderr) by task_create() when a new task is started. If set,
|
|
all files/drivers will appear to be closed in the new task except
|
|
for stdin, stdout, and stderr.
|
|
|
|
config NFILE_DESCRIPTORS_PER_BLOCK
|
|
int "The number of file descriptors per block"
|
|
default 8
|
|
range 3 99999
|
|
---help---
|
|
The number of file descriptors per block(one for each open)
|
|
|
|
config FILE_STREAM
|
|
bool "Enable FILE stream"
|
|
default !DEFAULT_SMALL
|
|
---help---
|
|
Enable the standard buffered input/output support
|
|
|
|
config NAME_MAX
|
|
int "Maximum size of a file name"
|
|
default 32
|
|
---help---
|
|
The maximum size of a file name.
|
|
|
|
config PATH_MAX
|
|
int "Maximum size of path name"
|
|
default 256
|
|
---help---
|
|
The maximum size of path name.
|
|
|
|
endmenu # Files and I/O
|
|
|
|
menuconfig PRIORITY_INHERITANCE
|
|
bool "Enable priority inheritance"
|
|
default n
|
|
---help---
|
|
Set to enable support for priority inheritance on mutexes and semaphores.
|
|
When this option is enabled, the initial configuration of all seamphores
|
|
and mutexes will be with priority inheritance enabled. That configuration
|
|
may not be appropriate in all cases (such as when the semaphore or mutex
|
|
is used for signaling). In such cases, priority inheritance can be
|
|
disabled for individual semaphores by calling:
|
|
|
|
int ret = sem_setprotocol(&sem, SEM_PRIO_NONE);
|
|
|
|
From applications, the functionally equivalent OS internal interface,
|
|
nxsem_set_protocol(), should be used within the OS
|
|
|
|
And for individual pthread mutexes by setting the protocol attribute
|
|
before initializing the mutex:
|
|
|
|
int ret = pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_NONE);
|
|
|
|
if PRIORITY_INHERITANCE
|
|
|
|
config SEM_PREALLOCHOLDERS
|
|
int "Number of pre-allocated holders"
|
|
default 4 if DEFAULT_SMALL
|
|
default 8 if !DEFAULT_SMALL
|
|
---help---
|
|
This setting is only used if priority inheritance is enabled.
|
|
It defines the maximum number of different threads (minus one) that
|
|
can take counts on a semaphore with priority inheritance support.
|
|
This may be set to zero if priority inheritance is disabled OR if you
|
|
are only using semaphores as mutexes (only one holder) OR if no more
|
|
than two threads participate using a counting semaphore.
|
|
|
|
endif # PRIORITY_INHERITANCE
|
|
|
|
config PRIORITY_PROTECT
|
|
bool "Enable priority protect"
|
|
default n
|
|
---help---
|
|
When a thread locks a mutex it inherits the priority ceiling of the
|
|
mutex, which is defined by the application as a mutex attribute.
|
|
|
|
menu "RTOS hooks"
|
|
|
|
config BOARD_EARLY_INITIALIZE
|
|
bool "Custom board early initialization"
|
|
default n
|
|
---help---
|
|
There are three points in time where you can insert custom,
|
|
board-specific initialization logic:
|
|
|
|
1) <arch>_board_initialize(): This function is used only for
|
|
initialization of very low-level things like configuration of
|
|
GPIO pins, power setting. The OS has not been initialized
|
|
at this point, so you cannot allocate memory or initialize
|
|
device drivers at this phase.
|
|
|
|
2) The next level of initialization is performed by a call to
|
|
up_initialize() (in arch/<arch>/src/common/up_initialize.c).
|
|
The OS has been initialized at this point and it is okay to
|
|
initialize drivers in this phase.
|
|
|
|
At this same point in time, the OS will also call a board-
|
|
specific initialization function named board_early_initialize()
|
|
if CONFIG_BOARD_EARLY_INITIALIZE is selected. The context in
|
|
which board_early_initialize() executes is suitable for early
|
|
initialization of most, simple device drivers and is a logical,
|
|
board-specific extension of up_initialize().
|
|
|
|
board_early_initialize() runs on the startup, initialization thread.
|
|
Some initialization operations cannot be performed on the start-up,
|
|
initialization thread. That is because the initialization thread
|
|
cannot wait for event. Waiting may be required, for example, to
|
|
mount a file system or or initialize a device such as an SD card.
|
|
For this reason, such driver initialize must be deferred to
|
|
board_late_initialize().
|
|
|
|
3) And, finally, just before the user application code starts.
|
|
|
|
If CONFIG_BOARD_LATE_INITIALIZE is selected, then an additional
|
|
initialization call will be performed in the boot-up sequence to a
|
|
function called board_late_initialize(). board_late_initialize()
|
|
will be called after up_initialize() is called and just before the
|
|
main application is started. This additional initialization
|
|
phase may be used, for example, to initialize more complex,
|
|
board-specific device drivers.
|
|
|
|
Waiting for events, use of I2C, SPI, etc are permissible in the
|
|
context of board_late_initialize(). That is because
|
|
board_late_initialize() will run on a temporary, internal kernel
|
|
thread.
|
|
|
|
config BOARD_LATE_INITIALIZE
|
|
bool "Custom board late initialization"
|
|
default n
|
|
---help---
|
|
There are three points in time where you can insert custom,
|
|
board-specific initialization logic:
|
|
|
|
1) <arch>_board_initialize(): This function is used only for
|
|
initialization of very low-level things like configuration of
|
|
GPIO pins, power setting. The OS has not been initialized
|
|
at this point, so you cannot allocate memory or initialize
|
|
device drivers at this phase.
|
|
|
|
2) The next level of initialization is performed by a call to
|
|
up_initialize() (in arch/<arch>/src/common/up_initialize.c).
|
|
The OS has been initialized at this point and it is okay to
|
|
initialize drivers in this phase.
|
|
|
|
At this same point in time, the OS will also call a board-
|
|
specific initialization function named board_early_initialize()
|
|
if CONFIG_BOARD_EARLY_INITIALIZE is selected. The context in
|
|
which board_early_initialize() executes is suitable for early
|
|
initialization of most, simple device drivers and is a logical,
|
|
board-specific extension of up_initialize().
|
|
|
|
board_early_initialize() runs on the startup, initialization thread.
|
|
Some initialization operations cannot be performed on the start-up,
|
|
initialization thread. That is because the initialization thread
|
|
cannot wait for event. Waiting may be required, for example, to
|
|
mount a file system or or initialize a device such as an SD card.
|
|
For this reason, such driver initialize must be deferred to
|
|
board_late_initialize().
|
|
|
|
3) And, finally, just before the user application code starts.
|
|
|
|
If CONFIG_BOARD_LATE_INITIALIZE is selected, then an additional
|
|
initialization call will be performed in the boot-up sequence to a
|
|
function called board_late_initialize(). board_late_initialize()
|
|
will be called after up_initialize() is called and just before the
|
|
main application is started. This additional initialization
|
|
phase may be used, for example, to initialize more complex,
|
|
board-specific device drivers.
|
|
|
|
Waiting for events, use of I2C, SPI, etc are permissible in the
|
|
context of board_late_initialize(). That is because
|
|
board_late_initialize() will run on a temporary, internal kernel
|
|
thread.
|
|
|
|
if BOARD_LATE_INITIALIZE
|
|
|
|
config BOARD_INITTHREAD_STACKSIZE
|
|
int "Board initialization thread stack size"
|
|
default DEFAULT_TASK_STACKSIZE
|
|
---help---
|
|
The size of the stack to allocate when starting the board
|
|
initialization thread.
|
|
|
|
config BOARD_INITTHREAD_PRIORITY
|
|
int "Board initialization thread priority"
|
|
default 240
|
|
---help---
|
|
The priority of the board initialization thread. This priority is
|
|
not a critical setting. No other application threads will be
|
|
started until the board initialization is completed. Hence, there
|
|
is very little competition for the CPU.
|
|
|
|
endif # BOARD_LATE_INITIALIZE
|
|
|
|
config SCHED_STARTHOOK
|
|
bool "Enable startup hook"
|
|
default n
|
|
---help---
|
|
Enable a non-standard, internal OS API call nxtask_starthook().
|
|
nxtask_starthook() registers a function that will be called on task
|
|
startup before that actual task entry point is called. The
|
|
starthook is useful, for example, for setting up automatic
|
|
configuration of C++ constructors.
|
|
|
|
endmenu # RTOS hooks
|
|
|
|
menu "Signal Configuration"
|
|
|
|
config SIG_PREALLOC_ACTIONS
|
|
int "Number of pre-allocated sigactions"
|
|
default 4
|
|
---help---
|
|
The number of pre-allocated sigaction structures.
|
|
|
|
config SIG_ALLOC_ACTIONS
|
|
int "Num of sigactions to allocate per time"
|
|
default 1
|
|
---help---
|
|
The number of sigactions to allocate per time. Note that
|
|
if this number is larger than 1, the allocation won't be
|
|
returned to the heap but kept in a free list for reuse.
|
|
|
|
config SIG_PREALLOC_IRQ_ACTIONS
|
|
int "Number of pre-allocated irq actions"
|
|
default 4 if DEFAULT_SMALL
|
|
default 8 if !DEFAULT_SMALL
|
|
---help---
|
|
The number of pre-allocated irq action structures.
|
|
|
|
config SIG_EVTHREAD
|
|
bool "Support SIGEV_THREAD"
|
|
default n
|
|
depends on !BUILD_KERNEL && SCHED_WORKQUEUE
|
|
select LIBC_USRWORK if BUILD_PROTECTED
|
|
---help---
|
|
Built in support for the SIGEV_THREAD signal deliver method.
|
|
|
|
NOTE: The current implementation uses a work queue to notify the
|
|
client. This, however, would only work in the FLAT build. A
|
|
different mechanism would need to be development to support this
|
|
feature on the PROTECTED or KERNEL build.
|
|
|
|
config SIG_EVTHREAD_HPWORK
|
|
bool "SIGEV_EVTHREAD use HPWORK"
|
|
default n
|
|
depends on SIG_EVTHREAD && SCHED_HPWORK
|
|
---help---
|
|
if selected, SIGEV_THREAD will use the high priority work queue.
|
|
If not, it will use the low priority work queue (if available).
|
|
|
|
REVISIT: This solution is non-optimal. Some notifications should
|
|
be high priority and others should be lower priority. Ideally, you
|
|
should be able to determine which work queue is used on a
|
|
notification-by-notification basis.
|
|
|
|
menuconfig SIG_DEFAULT
|
|
bool "Default signal actions"
|
|
default n
|
|
---help---
|
|
Enable to support default signal actions.
|
|
|
|
if SIG_DEFAULT
|
|
|
|
comment "Per-signal Default Actions"
|
|
|
|
config SIG_SIGKILL_ACTION
|
|
bool "Enable all SIGKILL signals"
|
|
default y
|
|
---help---
|
|
Enable the default action for SIGHUP SIGILL SIGTRAP SIGABRT SIGBUS
|
|
SIGFPE SIGINT SIGKILL SIGSEGV SIGQUIT SIGTERM SIGXCPU SIGXFSZ and
|
|
SIGSYS (terminate the task).
|
|
|
|
config SIG_SIGUSR1_ACTION
|
|
bool "SIGUSR1"
|
|
default n
|
|
---help---
|
|
Enable the default action for SIGUSR1 (terminate the task)
|
|
Make sure that your applications are expecting this POSIX behavior.
|
|
Backward compatible behavior would require that the application use
|
|
sigaction() to ignore SIGUSR1.
|
|
|
|
config SIG_SIGUSR2_ACTION
|
|
bool "SIGUSR2"
|
|
default n
|
|
---help---
|
|
Enable the default action for SIGUSR2 (terminate the task)
|
|
Make sure that your applications are expecting this POSIX behavior.
|
|
Backward compatible behavior would require that the application use
|
|
sigaction() to ignore SIGUSR2.
|
|
|
|
config SIG_SIGPIPE_ACTION
|
|
bool "SIGPIPE"
|
|
default n
|
|
---help---
|
|
Enable the default action for SIGPIPE (terminate the task).
|
|
|
|
config SIG_SIGALRM_ACTION
|
|
bool "SIGALRM SIGVTALRM"
|
|
default n
|
|
---help---
|
|
Enable the default action for SIGALRM AND SIGVTALRM(terminate the task)
|
|
Make sure that your applications are expecting this POSIX behavior.
|
|
Backward compatible behavior would require that the application use
|
|
sigaction() to ignore SIGALRM.
|
|
|
|
config SIG_SIGSTOP_ACTION
|
|
bool "SIGSTOP SIGTSTP SIGCONT SIGTTIN SIGTTOU"
|
|
default y
|
|
---help---
|
|
Enable the default action for SIGSTOP SIGTSTP SIGCONT SIGTTIN SIGTTOU
|
|
(suspend the task) and SIGCONT (resume the task).
|
|
|
|
config SIG_SIGPROF_ACTION
|
|
bool "SIGPROF"
|
|
default n
|
|
---help---
|
|
Enable the default action for SIGPROF (nxsig_abnormal_termination)
|
|
Make sure that your applications are expecting this POSIX behavior.
|
|
Backward compatible behavior would require that the application use
|
|
sigaction() to ignore SIGPROF.
|
|
|
|
config SIG_SIGPOLL_ACTION
|
|
bool "SIGPOLL"
|
|
default n
|
|
depends on FS_AIO
|
|
---help---
|
|
Enable the default action for SIGPOLL (terminate the task)
|
|
Make sure that your applications are expecting this POSIX behavior.
|
|
Backward compatible behavior would require that the application use
|
|
sigaction() to ignore SIGPOLL.
|
|
|
|
endif # SIG_DEFAULT
|
|
|
|
endmenu # Signal Configuration
|
|
|
|
menu "Message Queue Options"
|
|
depends on !DISABLE_MQUEUE || !DISABLE_MQUEUE_SYSV
|
|
|
|
config PREALLOC_MQ_MSGS
|
|
int "Number of pre-allocated messages"
|
|
default 4 if DEFAULT_SMALL
|
|
default 8 if !DEFAULT_SMALL
|
|
---help---
|
|
The number of pre-allocated message structures. The system manages
|
|
a pool of preallocated message structures to minimize dynamic allocations
|
|
|
|
config PREALLOC_MQ_IRQ_MSGS
|
|
int "Number of pre-allocated irq messages"
|
|
default 4 if DEFAULT_SMALL
|
|
default 8 if !DEFAULT_SMALL
|
|
---help---
|
|
The number of pre-allocated irq message structures.
|
|
|
|
config MQ_MAXMSGSIZE
|
|
int "Maximum message size"
|
|
default 32
|
|
---help---
|
|
Message structures are allocated with a fixed payload size given by this
|
|
setting (does not include other message structure overhead.
|
|
|
|
config DISABLE_MQUEUE_NOTIFICATION
|
|
bool "Disable POSIX message queue notification"
|
|
default DEFAULT_SMALL
|
|
---help---
|
|
Disable POSIX message queue notification
|
|
|
|
endmenu # POSIX Message Queue Options
|
|
|
|
config MODULE
|
|
bool "Enable loadable OS modules"
|
|
default n
|
|
select LIBC_MODLIB
|
|
select ARCH_USE_TEXT_HEAP if ARCH_HAVE_TEXT_HEAP
|
|
---help---
|
|
Enable support for loadable OS modules. Default: n
|
|
|
|
menu "Work queue support"
|
|
|
|
config SCHED_WORKQUEUE
|
|
# bool "Enable worker thread"
|
|
bool
|
|
default n
|
|
---help---
|
|
Create dedicated "worker" threads to handle delayed or asynchronous
|
|
processing.
|
|
|
|
config WQUEUE_NOTIFIER
|
|
bool "Generic work notifier"
|
|
default n
|
|
depends on SCHED_WORKQUEUE
|
|
---help---
|
|
Enable building of work queue notifier logic that will execute a
|
|
worker function an event occurs. This is is a general purpose
|
|
notifier, but was developed specifically to support poll() logic
|
|
where the poll must wait for an resources to become available.
|
|
|
|
config SCHED_HPWORK
|
|
bool "High priority (kernel) worker thread"
|
|
default n
|
|
select SCHED_WORKQUEUE
|
|
---help---
|
|
Create a dedicated high-priority "worker" thread to handle delayed
|
|
processing from interrupt handlers. This feature is required for
|
|
some drivers but, if there are no complaints, can be safely
|
|
disabled. The high priority worker thread also performs garbage
|
|
collection -- completing any delayed memory deallocations from
|
|
interrupt handlers. If the high-priority worker thread is disabled,
|
|
then that clean up will be performed either by (1) the low-priority
|
|
worker thread, if enabled, and if not (2) the IDLE thread instead
|
|
(which runs at the lowest of priority and may not be appropriate if
|
|
memory reclamation is of high priority)
|
|
|
|
For other, less-critical asynchronous or delayed process, the
|
|
low-priority worker thread is recommended.
|
|
|
|
if SCHED_HPWORK
|
|
|
|
config SCHED_HPNTHREADS
|
|
int "Number of high-priority worker threads"
|
|
default 1
|
|
---help---
|
|
This options selects multiple, high-priority threads. This is
|
|
essentially a "thread pool" that provides multi-threaded servicing
|
|
of the high-priority work queue. This breaks the serialization
|
|
of the "queue" (hence, it is no longer a queue at all).
|
|
|
|
CAUTION: Some drivers may use the work queue to serialize
|
|
operations. They may also use the high-priority work queue if it is
|
|
available. If there are multiple high-priority worker threads, then
|
|
this can result in the loss of that serialization. There may be
|
|
concurrent driver operations running on different HP threads and
|
|
this could lead to a failure. You may need to visit the use of the
|
|
HP work queue on your configuration is you select
|
|
CONFIG_SCHED_HPNTHREADS > 1
|
|
|
|
config SCHED_HPWORKPRIORITY
|
|
int "High priority worker thread priority"
|
|
default 224
|
|
---help---
|
|
The execution priority of the higher priority worker thread.
|
|
|
|
The higher priority worker thread is intended to serve as the
|
|
"bottom" half for device drivers. As a consequence it must run at
|
|
a very high, fixed priority. Typically, it should be the highest
|
|
priority thread in your system. Default: 224
|
|
|
|
For lower priority, application oriented worker thread support,
|
|
please consider enabling the lower priority work queue. The lower
|
|
priority work queue runs at a lower priority, of course, but has
|
|
the added advantage that it supports "priority inheritance" (if
|
|
PRIORITY_INHERITANCE is also selected): The priority of the lower
|
|
priority worker thread can then be adjusted to match the highest
|
|
priority client.
|
|
|
|
config SCHED_HPWORKSTACKSIZE
|
|
int "High priority worker thread stack size"
|
|
default DEFAULT_TASK_STACKSIZE
|
|
---help---
|
|
The stack size allocated for the worker thread. Default: 2K.
|
|
|
|
endif # SCHED_HPWORK
|
|
|
|
config SCHED_LPWORK
|
|
bool "Low priority (kernel) worker thread"
|
|
default n
|
|
select SCHED_WORKQUEUE
|
|
---help---
|
|
If SCHED_LPWORK is defined then a lower-priority work queue will
|
|
be created. This lower priority work queue is better suited for
|
|
more extended, application oriented processing (such as file system
|
|
clean-up operations or asynchronous I/O)
|
|
|
|
if SCHED_LPWORK
|
|
|
|
config SCHED_LPNTHREADS
|
|
int "Number of low-priority worker threads"
|
|
default 1 if !FS_AIO
|
|
default 4 if FS_AIO
|
|
---help---
|
|
This options selects multiple, low-priority threads. This is
|
|
essentially a "thread pool" that provides multi-threaded servicing
|
|
of the low-priority work queue. This breaks the serialization
|
|
of the "queue" (hence, it is no longer a queue at all).
|
|
|
|
This options is required to support, for example, I/O operations
|
|
that stall waiting for input. If there is only a single thread,
|
|
then the entire low-priority queue processing stalls in such cases.
|
|
Such behavior is necessary to support asynchronous I/O, AIO (for
|
|
example).
|
|
|
|
CAUTION: Some drivers may use the work queue to serialize
|
|
operations. They may also use the low-priority work queue if it is
|
|
available. If there are multiple low-priority worker threads, then
|
|
this can result in the loss of that serialization. There may be
|
|
concurrent driver operations running on different LP threads and
|
|
this could lead to a failure. You may need to visit the use of the
|
|
LP work queue on your configuration is you select
|
|
CONFIG_SCHED_LPNTHREADS > 1
|
|
|
|
config SCHED_LPWORKPRIORITY
|
|
int "Low priority worker thread priority"
|
|
default 100
|
|
---help---
|
|
The minimum execution priority of the lower priority worker thread.
|
|
|
|
The lower priority worker thread is intended support application-
|
|
oriented functions. The lower priority work queue runs at a lower
|
|
priority, of course, but has the added advantage that it supports
|
|
"priority inheritance" (if PRIORITY_INHERITANCE is also selected):
|
|
The priority of the lower priority worker thread can then be
|
|
adjusted to match the highest priority client. Default: 100
|
|
|
|
NOTE: This priority inheritance feature is not automatic. The
|
|
lower priority worker thread will always a fixed priority unless
|
|
you implement logic that calls lpwork_boostpriority() to raise the
|
|
priority of the lower priority worker thread (typically called
|
|
before scheduling the work) and then call the matching
|
|
lpwork_restorepriority() when the work is completed (typically
|
|
called within the work handler at the completion of the work).
|
|
Currently, only the NuttX asynchronous I/O logic uses this dynamic
|
|
prioritization feature.
|
|
|
|
The higher priority worker thread, on the other hand, is intended
|
|
to serve as the "bottom" half for device drivers. As a consequence
|
|
it must run at a very high, fixed priority. Typically, it should
|
|
be the highest priority thread in your system.
|
|
|
|
config SCHED_LPWORKPRIOMAX
|
|
int "Low priority worker thread maximum priority"
|
|
default 176
|
|
depends on PRIORITY_INHERITANCE
|
|
---help---
|
|
The maximum execution priority of the lower priority worker thread.
|
|
|
|
The lower priority worker thread is intended support application-
|
|
oriented functions. The lower priority work queue runs at a lower
|
|
priority, of course, but has the added advantage that it supports
|
|
"priority inheritance" (if PRIORITY_INHERITANCE is also selected):
|
|
The priority of the lower priority worker thread can then be
|
|
adjusted to match the highest priority client.
|
|
|
|
The higher priority worker thread, on the other hand, is intended
|
|
to serve as the "bottom" half for device drivers. As a consequence
|
|
it must run at a very high, fixed priority. Typically, it should
|
|
be the highest priority thread in your system.
|
|
|
|
This value provides an upper limit on the priority of the lower
|
|
priority worker thread. This would be necessary, for example, if
|
|
the higher priority worker thread were to defer work to the lower
|
|
priority thread. Clearly, in such a case, you would want to limit
|
|
the maximum priority of the lower priority work thread. Default:
|
|
176
|
|
|
|
config SCHED_LPWORKSTACKSIZE
|
|
int "Low priority worker thread stack size"
|
|
default DEFAULT_TASK_STACKSIZE
|
|
---help---
|
|
The stack size allocated for the lower priority worker thread. Default: 2K.
|
|
|
|
endif # SCHED_LPWORK
|
|
endmenu # Work Queue Support
|
|
|
|
menu "Stack and heap information"
|
|
|
|
config DEFAULT_TASK_STACKSIZE
|
|
int "The default stack size for tasks"
|
|
default 2048
|
|
---help---
|
|
The default stack size for tasks.
|
|
|
|
config IDLETHREAD_STACKSIZE
|
|
int "Idle thread stack size"
|
|
default 1024
|
|
---help---
|
|
The size of the initial stack used by the IDLE thread. The IDLE thread
|
|
is the thread that (1) performs the initial boot of the system up to the
|
|
point where start-up application is spawned, and (2) there after is the
|
|
IDLE thread that executes only when there is no other thread ready to run.
|
|
|
|
config PTHREAD_STACK_MIN
|
|
int "Minimum pthread stack size"
|
|
default 256
|
|
---help---
|
|
Minimum pthread stack size
|
|
|
|
config PTHREAD_STACK_DEFAULT
|
|
int "Default pthread stack size"
|
|
default DEFAULT_TASK_STACKSIZE
|
|
---help---
|
|
Default pthread stack size
|
|
|
|
endmenu # Stack and heap information
|
|
|
|
config SCHED_BACKTRACE
|
|
bool "Stack BackTrace"
|
|
default "n"
|
|
---help---
|
|
This option enables stack backtrace support in the NuttX
|
|
using the information automatically generated by the
|
|
compiler or architecture specific approach when ARCH_HAVE_BACKTRACE
|
|
is selected
|
|
|
|
config GROUP_KILL_CHILDREN_TIMEOUT_MS
|
|
int "Group kill children timeout"
|
|
default -1
|
|
depends on !DISABLE_PTHREAD && SIG_SIGKILL_ACTION
|
|
---help---
|
|
Kill children a SIGQUIT signal before cancel them,
|
|
< 0 means wait until all the child thread exit
|
|
> 0 means wait timeout
|
|
= 0 means don't do kill signal
|
|
|
|
config PID_INITIAL_COUNT
|
|
int "Initial length of pid table"
|
|
default 8 if DEFAULT_SMALL
|
|
default 16 if !DEFAULT_SMALL
|
|
---help---
|
|
This is the initial length of pid table, which the system
|
|
can still expand when needed. It is rounded up to power of
|
|
two by current implementation. If the number of threads in
|
|
your system is known at design time, setting this to it.
|
|
|
|
config SCHED_EVENTS
|
|
bool "Schedule Event objects"
|
|
default n
|
|
---help---
|
|
This option enables event objects. Threads may wait on event
|
|
objects for specific events, but both threads and ISRs may deliver
|
|
events to event objects.
|
|
|
|
config ASSERT_PAUSE_CPU_TIMEOUT
|
|
int "Timeout in milisecond to pause another CPU when assert"
|
|
default 2000
|
|
depends on SMP
|
|
---help---
|
|
Timeout in milisecond to pause another CPU when assert. Only available
|
|
when SMP is enabled.
|