User-space networking stack API allows user-space daemon to
provide TCP/IP stack implementation for NuttX network.
Main use for this is to allow use and seamless integration of
HW-provided TCP/IP stacks to NuttX.
For example, user-space daemon can translate /dev/usrsock
API requests to HW TCP/IP API requests while rest of the
user-space can access standard socket API, with socket
descriptors that can be used with NuttX system calls.
Entropy pool gathers environmental noise from device drivers, user-space, etc., and returns good random numbers, suitable for cryptographic use. Based on entropy pool design from *BSDs and uses BLAKE2Xs algorithm for CSPRNG output.
Patch also adds /dev/urandom support for using entropy pool RNG and new 'getrandom' system call for getting randomness without file-descriptor usage (thus avoiding file-descriptor exhaustion attacks). The 'getrandom' interface is similar as 'getentropy' and 'getrandom' available on OpenBSD and Linux respectively.
gcc version 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589] (GNU Tools for ARM Embedded Processors)
gives error:
local/local_connect.c:188:7: error: '_local_semtake' is static but used in inline function 'local_stream_connect' which is not static [-Werror]
this is due to compiler enforcing ISO/IEC 9899:1999 6.7.4.3: "An inline definition of a function with external linkage shall not contain a definition of a modifiable object with static storage duration, and shall not contain a reference to an identifier with internal linkage."
Fix by making inlined caller to have internal linkage as well.
This was a consequence of the recent robust mutex changes. If robust mutexes are selected, then each mutex that a thread takes is retained in a list in threads TCB. If the thread exits and that list is not empty, then we know that the thread exitted while holding mutexes. And, in that case, each will be marked as inconsistent and the any waiter for the thread is awakened.
For the case of pthread_mutex_trywait(), the mutex was not being added to the list! while not usually a fatal error, this was caught by an assertion when pthread_mutex_unlock() was called: It tried to remove the mutex from the TCB list and it was not there when, of course, it shoule be.
The fix was to add pthread_mutex_trytake() which does sem_trywait() and if successful, does correctly add the mutext to the TCB list. This should eliminated the assertion.
Gregory Nutt