This commit changes only ones with the default 2048 and
leaves the others.
E.g. this leaves SYSTEM_RAMTEST_STACKSIZE, whose default is 1024.
I guess those need to be inspected one-by-one.
Author: anchao <anchao@pinecone.net>
apps/, most main() function: Correct CONFIG_BUILD_LOADABLE usage
Loadable apps/: Correct loadable symbol table generate
apps/system/ubloxmodem: Fix build break
apps/examples/ostest: start restart/waitpid/user test from main loop
apps/nshlib: Expand reboot and poweroff commands to include a second, optional mode argument
Author: Gregory Nutt <gnutt@nuttx.org>
An attempt to fix build issues. Does not work.
apps/examples/ostest: Fix some inappropriate renaming of static functions introduced with recent patches.
apps/builtin/exec_builtin.c: Fix a error introduced by recent comments. Found in build testing.
Author: anchao <anchao@pinecone.net>
apps/builtin/exec_builtin.c: Try posix_spawn if builtin apps do not have have an entry point.
apps/Application.mk: introduce MODULE config to simplify tristate(m)
apps/nsh: Change the nuttx shell module type to tristate
apps: Add loadable application support
script/mksymtab: Generate symbol table name by default
apps/builtin: Allow loadable applications can register with apps/builtin.
apps/builtin/exec_builtin.c: Try posix_spawn if builtin apps do not have have an entry point.
apps/Application.mk: introduce MODULE config to simplify tristate(m)
apps/nsh: Change the nuttx shell module type to tristate
apps: Add loadable application support
script/mksymtab: Generate symbol table name by default
apps/builtin: Allow loadable applications can register with apps/builtin.
- The maximum block size is now configuration setting in order to give finer control over memory usage.
- The compression/decompression buffers have been moved out the stack and are now global variables. This eliminates the need to set large stack sizes to use this utility.
- Added semaphore protection of all global variables for the case of the FLAT or PROTECTED builds. Unlike the KERNEL build, the same global variables will be used by each instance of the LZF utility. If you want thread safety, then you must either (a) serialize all access to the global variables, or (b) pack the global variables into a structure and allocate that structure on each execution of lzf_main().
