On Wed, 2020-04-22 at 17:35 -0300, Dan Gora wrote: > On Wed, Apr 22, 2020 at 5:14 PM Mattias Rönnblom > <mattias.ronnb...@ericsson.com> wrote: > > On 2020-04-22 19:44, Dan Gora wrote: > > > On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom > > > <mattias.ronnb...@ericsson.com> wrote: > > > > On 2020-04-21 21:54, Dan Gora wrote: > > > > > The getentropy() function was introduced into glibc v2.25 and so is > > > > > not available on all supported platforms. Previously, if DPDK was > > > > > compiled (using meson) on a system which has getentropy(), it would > > > > > introduce a dependency on glibc v2.25 which would prevent that binary > > > > > from running on a system with an older glibc. Similarly if DPDK was > > > > > compiled on a system which did not have getentropy(), getentropy() > > > > > could not be used even if the execution system supported it. > > > > > > > > > > Introduce a new static function, __rte_getentropy() which will try to > > > > > resolve the getentropy() function dynamically using dlopen()/dlsym(), > > > > > returning failure if the getentropy() function cannot be resolved or > > > > > if it fails. > > > > > > > > Two other options: providing a DPDK-native syscall wrapper for > > > > getrandom(), or falling back to reading /dev/urandom. Have you > > > > considered any of those two options? If so, why do you prefer > > > > dlopen()/dlsym()? > > > I didn't give any thought at all to using /dev/urandom. The goal was > > > not really to change how the thing worked, just to remove the > > > dependency on glibc 2.25. > > > > /dev/urandom is basically only a different interface to the same > > underlying mechanism.
This is not the whole story though - while the end result when all works is the same, there are important differences in getting there. There's a reason a programmatic interface was added - it's just better in general. Just to name one - opening files has implications for LSMs like SELinux. You now need a specific policy to allow it, which means applications that upgrade from one version of DPDK to the next will break. In general, I do not think we should go backwards. The programmatic interface to the random pools are good and we should use them by default - of course by all means add fallbacks to urandom if they are not available. But as Stephen said glibc generally does not support compiling on new + running on old - so if it's not this that breaks, it will be something else. -- Kind regards, Luca Boccassi
