> If the GRND_RANDOM flags bit is set, then draw from the /dev/random pool instead of /dev/urandom pool. The /dev/random pool is limited based on the entropy

> If the GRND_RANDOM flags bit is set, then draw from the /dev/random pool instead of /dev/urandom pool. The /dev/random pool is limited based on the entropy that can be obtained from environmental noise, so if there is insufficient entropy, the requested number of bytes may not be returned. If there is no entropy available at all, getrandom(2) will either return an error with errno set to EAGAIN, or block if the GRND_BLOCK flags bit is set. > If the GRND_RANDOM flags bit is not set, then the /dev/raundom pool will be used. Unlike reading from the /dev/urandom, if the urandom pool has not been sufficiently initialized, getrandom(2) will either return an error with errno set to EGAIN, or block if the GRND_BLOCK flags bit is set. Is this complexity necessary? I'm concerned that this will be hard to use properly as there's lots of different behaviours based on the parameters, and different types of failure modes. Security code that is hard to call right or hard to understand tends to get misused, causing security bugs in application code.