The hwtimer_wait test was tortured with the
following script which ran several hours.
----
make clean all-debug
while :
do
date
./bin/native/hwtimer_wait.elf > log &
pid=$!
sleep 20
success=$(cat log|grep success)
if [ "$success" != "success" ]
then
date
echo "BUG"
exit
fi
kill $pid
done
----
Closes#715.
As discussed in #2725, this commit renames a number of stacksize constants to
better convey their intended usage. In addition, constants for thread priority
are given a `THREAD_` prefix. Changes are:
* KERNEL_CONF_STACKSIZE_PRINTF renamed to THREAD_EXTRA_STACKSIZE_PRINTF
* KERNEL_CONF_STACKSIZE_DEFAULT renamed to THREAD_STACKSIZE_DEFAULT
* KERNEL_CONF_STACKSIZE_IDLE renamed to THREAD_STACKSIZE_IDLE
* KERNEL_CONF_STACKSIZE_MAIN renamed to THREAD_STACKSIZE_MAIN
* Move thread stacksizes from kernel.h to thread.h, since the prefix changed
* PRIORITY_MIN renamed to THREAD_PRIORITY_MIN
* PRIORITY_IDLE renamed to THREAD_PRIORITY_IDLE
* PRIORITY_MAIN renamed to THREAD_PRIORITY_MAIN
* Move thread priorities from kernel.h to thread.h since the prefix has changed
* MINIMUM_STACK_SIZE renamed to THREAD_STACKSIZE_MINIMUM for consistency
Per default random data is read from `/dev/random` now.
If specified (e.g. `-s 4711`), data is generated by calls to POSIX
random function like before. The POSIX random API is initialize with
the given seed (`srandom(4711);` in this example).
- adopt test name to new scheme
- make cppcheck happy / dont overwrite the target memory location twice
- fix license header
- don't redefine define if it already exists
- don't write more cpuid than is defined as size
Instead of using differing integer types use kernel_pid_t for process
identifier. This type is introduced in a new header file to avoid
circular dependencies.
When using socket stdio, add option to replay what has been written to
stdout while not connected (`-r`).
The implementation is to simply use the existing log file (which is
implicitly created when the option is used), and read from it until
EOF upon reconnect.
closes#476
Real IEEE 802.15.4 transceivers have a payload of 127. Hence, for
testing - particular 6lowpan - it would make sense to have the same
limitation in nativenet. Especially to test fragmentation this is
helpful.
