Hello Andrei,

On Tue, 29 Jan 2019 13:35:19 +0000
"Andrei Gansari" <andrei.gansari@...> wrote:

Hello everyone,

I have a question regarding TEST_RANDOM_GENERATOR.
When building networking samples for boards with entropy devices is
get the warning: warning: TEST_RANDOM_GENERATOR (defined at
subsys/random/Kconfig:8) was assigned the value 'y' but got the value
'n'.

We find in subsys/random/Kconfig
TEST_RANDOM_GENERATOR depends on !ENTROPY_HAS_DRIVER
ENTROPY_DEVICE_RANDOM_GENERATOR depends on ENTROPY_HAS_DRIVER

Most networking samples have set TEST_RANDOM_GENERATOR=y and as I
understand it's for pseudo-random number generation. Boards that have
entropy devices (ENTROPY_HAS_DRIVER) will disable
TEST_RANDOM_GENERATOR.

When setting TEST_RANDOM_GENERATOR we just want a random generator or
we want a predictable/intuitive random number generator?

We want to have a "random generator" device be present in Zephyr
setup, which various subsystems then can use (instead of failing). So,
TEST_RANDOM_GENERATOR is a fallback choice which is always available.
For example, it's available in qemu_* boards, which otherwise don't
have a "real" randomgen. That's why you see TEST_RANDOM_GENERATOR in
many networking samples - the only way to make networking samples
accessing to *anyone* is to make sure they run with qemu networking.

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.

If we want
both type of generators, then we could remove ENTROPY_HAS_DRIVER
check on TEST_RANDOM_GENERATOR?

Is this an issue?


Andrei G.

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hello Alberto,

On Wed, 30 Jan 2019 07:15:41 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@...> wrote:

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.

That's the native posix one ;)

D'oh, I stand corrected. Now I remember it, Bluetooth simulation
support, right?

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hi,
The native_posix board does not use the Bluetooth simulator.
Its random generator is deterministic, but can be seeded ( --seed=<random_seed>) to enable reproducible tests(*1).

The nrf52_bsim board (*2) does use the Bluetooth simulator (BabbleSim, a.k.a. bsim (*3)), and has another random generator (a model of the nRF5x RNG HW) which is also deterministic and can be seeded.

What these 2 Zephyr targets have in common is that both are based on the POSIX architecture. So the result of building targeting these boards is actually a native executable for the host computer, which the developer can run and debug like a normal Linux program.
Apart from this, the nrf52_bsim RADIO HW models, use the BabbleSim physical layer simulator to simulate the radio activity, and communicate with other simulated devices.

1 https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/board.html#peripherals
2 https://docs.zephyrproject.org/latest/boards/posix/nrf52_bsim/doc/board.html
3 https://babblesim.github.io

BR
Alberto