2019-01-24 21:31:43 +08:00
|
|
|
# Networking config
|
|
|
|
|
CONFIG_NETWORKING=y
|
2020-05-21 05:18:59 +08:00
|
|
|
CONFIG_NET_IPV4=n
|
2019-01-24 21:31:43 +08:00
|
|
|
CONFIG_NET_IPV6=y
|
|
|
|
|
CONFIG_NET_UDP=y
|
2019-09-03 21:25:36 +08:00
|
|
|
CONFIG_NET_TCP=y
|
2019-01-24 21:31:43 +08:00
|
|
|
CONFIG_NET_SOCKETS=y
|
|
|
|
|
CONFIG_NET_SOCKETS_POSIX_NAMES=y
|
|
|
|
|
CONFIG_POSIX_MAX_FDS=10
|
|
|
|
|
|
|
|
|
|
# Network driver config
|
|
|
|
|
CONFIG_TEST_RANDOM_GENERATOR=y
|
|
|
|
|
|
|
|
|
|
# Network address config
|
|
|
|
|
CONFIG_NET_CONFIG_SETTINGS=y
|
|
|
|
|
CONFIG_NET_CONFIG_MY_IPV6_ADDR="2001:db8::1"
|
2020-05-21 04:59:40 +08:00
|
|
|
CONFIG_NET_CONFIG_NEED_IPV6=y
|
2019-01-24 21:31:43 +08:00
|
|
|
|
|
|
|
|
CONFIG_MAIN_STACK_SIZE=2048
|
|
|
|
|
|
|
|
|
|
CONFIG_ZTEST=y
|
tests: socket: poll, select: Fix non-blocking timing tests
As written originally, the tests assumed that if k_uptime_get_32()
returns times in milliseconds, that it also has millisecond
resolution. That however doesn't have to be the case, and indeed,
default timer interrupt period used by Zephyr is 10ms, and so system
time is incremented in such units. So, instead of "<= 1" tests to
account for timing increment, use "<= FUZZ".
For blocking tests, increase the timeout from previously used 10ms,
so we can reliably tests delays under the conditions described.
Also, enable CONFIG_QEMU_TICKLESS_WORKAROUND. Most other
timing-related tests have this enabled, and it may affect
stability of QEMU testing too.
Fixes: #12994
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2019-02-04 19:39:53 +08:00
|
|
|
|
2019-08-30 19:59:56 +08:00
|
|
|
CONFIG_NET_TEST=y
|
|
|
|
|
CONFIG_NET_LOOPBACK=y
|
