sched_releasetcb() will normally free the stack allocated for a task. However, a task with a custom, user-managed stack may be created using nxtask_init() followed by nxtask_activer. If such a custom stack is used then it must not be free in this many or a crash will most likely result.
This chagne addes a flag call TCB_FLAG_CUSTOM_STACK that may be passed in the the pre-allocted TCB to nxtask_init(). This flag is not used internally anywhere in the OS except that if set, it will prevent sched_releasetcb() from freeing that custom stack.
Add trivial function nxtask_uninit(). This function will undo all operations on a TCB performed by task_init() and release the TCB by calling kmm_free(). This is intended primarily to support error recovery operations after a successful call to task_init() such was when a subsequent call to task_activate fails.
That error recovery is trivial but not obvious. This helper function should eliminate confusion about what to do to recover after calling nxtask_init()
-Move task_init() and task_activate() prototypes from include/sched.h to include/nuttx/sched.h. These are internal OS functions and should not be exposed to the user.
-Remove references to task_init() and task_activate() from the User Manual.
-Rename task_init() to nxtask_init() since since it is an OS internal function
-Rename task_activate() to nxtask_activate since it is an OS internal function
Functions within the OS must never set the errno value. fs_fdopen() was setting the errno value. Now, after some parameter changes, it reports errors via a negated errno integer return value as do most all other internal OS functions.
1. Internal scheduler functions should begin with nxsched_, not sched_
2. Follow the consistent naming patter of https://cwiki.apache.org/confluence/display/NUTTX/Naming+of+OS+Internal+Functions
# clock_systimer -> clock_systime_tick
# clock_systimespec -> clock_systime_timespec
sched_oneshot_extclk -> nxsched_oneshot_extclk
sched_period_extclk -> nxsched_period_extclk
# nxsem_setprotocol -> nxsem_set_protocol
# nxsem_getprotocol -> nxsem_get_protocol
# nxsem_getvalue -> nxsem_get_value
nxsem_initholders -> nxsem_initialize_holders
nxsem_addholder -> nxsem_add_holder
nxsem_addholder_tcb -> nxsem_add_holder_tcb
nxsem_boostpriority -> nxsem_boost_priority
nxsem_releaseholder -> nxsem_release_holder
nxsem_restorebaseprio -> nxsem_restore_baseprio
Some planned name changed were skipped for now because they effect too many files (and would require many hours of coding style fixups).
All complaints fixed except for those that were not possible to fix:
- Used of Mixed case identifier in ESP32 files. These are references to Expressif ROM functions which are outside of the scope of NuttX.
Linux Programmer's Manual:
SEM_POST(3)
NAME
sem_post - unlock a semaphore
...
ERRORS
...
EOVERFLOW
The maximum allowable value for a semaphore would be exceeded.
Change-Id: I57c1a797a5510df4290a10aa2f3106fd01754b37
Signed-off-by: chao.an <anchao@xiaomi.com>
1. Add missing conditional logic in include/sys/syscall_lookup.h
2. CONFIG_NPTHREAD_KEYS removed from code but was still in sched/Kconfig
3. Refresh all configurations affected by PR 1007
4. syscall/syscall_funclookup.c needs to include nuttx/tls.h
1. Move pthread-specific data files from sched/pthread/ to libs/libc/pthread.
2. Remove pthread-specific data functions from syscalls.
3. Implement tls_alloc() and tls_free() with system calls.
4. Reimplement pthread_key_create() and pthread_key_free() using tls_alloc() and tls_free().
5. Reimplement pthread_set_specific() and pthread_get_specicif() using tls_set_value() and tls_get_value()
- Remove per-thread errno from the TCB structure (pterrno)
- Remove get_errno() and set_errno() as functions. The macros are still available as stubs and will be needed in the future if we need to access the errno from a different address environment (KERNEL mode).
- Add errno value to the tls_info_s structure definitions
- Move sched/errno to libs/libc/errno. Replace old TCB access to the errno with TLS access to the errno.
Revert a portion of eca7059785 that
causes compiler warnings about unused variables if nx_start() is not
initializing any of the user-mode heap, kernel-mode heap, or page
allocator:
init/nx_start.c: In function 'nx_start':
init/nx_start.c:552:14: warning: unused variable 'heap_size'
[-Wunused-variable]
size_t heap_size;
^~~~~~~~~
init/nx_start.c:551:17: warning: unused variable 'heap_start'
[-Wunused-variable]
FAR void *heap_start;
^~~~~~~~~~
See dev@nuttx.apache.org mailing list discussion "New unused variables
warning in nx_start()" starting 6 May 2020, archived here:
https://lists.apache.org/thread.html/r3900727e6a06f4445d6eb881d065119ba6647daab89600c3d45d1424%40%3Cdev.nuttx.apache.org%3E
sched/init/nx_start.c:
* If none of MM_KERNEL_USRHEAP_INIT, CONFIG_MM_KERNEL_HEAP, or
CONFIG_MM_PGALLOC are defined, the variables heap_start and
heap_size were declared but never used.
* This change reinstates wrapping the block with a preprocessor
conditional to prevent the variables being declared if they will
not be used. This preprocessor condition was removed in the
above-mentioned commit.
There is a DEBUGPANIC in some logic. This happens if a a task exists at certain points with priority inheritance enabled. This event was not expected in the original design (although logic was provided to support it). Since, apparently, it does happen, the DEBUGPANIC must be removed.
Noted by Brennan Ashton.
The sched_get_stackinfo() interface was just added. However, it occurs to me that it is a dangerous feature and could lead to security problems. In FLAT and PROTECTED modes, if you get access to any other threads stack, you could do harm.
This commit adds some level of security. Basically, it implements these rules:
1. Any thread may query its own stack,
2. A kernel thread may query the stack of any other thread
3. Application threads, however, may query only the stacks of threads within the same task group, i.e., the main thread and any of the child pthreads created with the main thread as a parent or grandparent or great-grandpart ...
The new OS interface, sched_get_stackinfo() combines two pthread-specific interfaces into a single generic interface. The existing pthread_get_stackaddr_np() and pthread_get_stacksize_np() are moved from sched/pthread to libs/libc/pthread.
There are two motivations for this change: First, it reduces the number of system calls. Secondly, it adds a common hook that is going to used for a future implementation of TLS.
Sockets are created in two steps:
1. The socket is allocated, then
2. The socket is initialized.
In SMP mode, there is a possibility that a pthread executing one CPU may create a new task while a pthread on another CPU has allocated the socket but not yet initialized it. This commit updates the socket clone test to assure that the socket is both allocated and initailized.
Without the change, it is possible that uninitialized sockets could be cloned, leading to errors later in the newly started task.
These warnings fix a class of warnings that I saw during CI checks for macOS sim builds. For example:
devif/devif_callback.c:111:49: warning: for loop has empty body [-Wempty-body]
prev = curr, curr = curr->nxtdev);
^
devif/devif_callback.c:111:49: note: put the semicolon on a separate line to silence this warning
I did not put the semi-colon on a separate line, but used braces.
This commit resolves issue #620:
Remove CONFIG_CAN_PASS_STRUCTS #620
The configuration option CONFIG_CAN_PASS_STRUCTS was added many years ago to support an old version of the SDCC compiler. That compiler is currently used only with the Z80 and Z180 targets. The limitation of that old compiler was that it could not pass structures or unions as either inputs or outputs. For example:
#ifdef CONFIG_CAN_PASS_STRUCTS
struct mallinfo mallinfo(void);
#else
int mallinfo(FAR struct mallinfo *info);
#endif
And even leads to violation of a few POSIX interfaces like:
#ifdef CONFIG_CAN_PASS_STRUCTS
int sigqueue(int pid, int signo, union sigval value);
#else
int sigqueue(int pid, int signo, FAR void *sival_ptr);
#endif
This breaks the 1st INVIOLABLES rule:
Strict POSIX compliance
-----------------------
o Strict conformance to the portable standard OS interface as defined at
OpenGroup.org.
o A deeply embedded system requires some special support. Special
support must be minimized.
o The portable interface must never be compromised only for the sake of
expediency.
o Expediency or even improved performance are not justifications for
violation of the strict POSIX interface
Also, it appears that the current SDCC compilers have resolve this issue and so, perhaps, this is no longer a problem: z88dk/z88dk#1132
NOTE: This commit cannot pass the PR checks because it depends on matching changes to the apps/ directory.
