On Fri, Sep 20, 2019 at 04:30:20PM -0700, Andy Lutomirski wrote: > So I think that just improving the > getrandom()-is-blocking-on-x86-and-arm behavior, adding GRND_INSECURE > and GRND_SECURE_BLOCKING, and adding the warning if 0 is passed is > good enough. I think so as well. Anyway, keep in mind that *with a sane API*, userland can improve very quickly (faster than kernel deployments in field). But userland developers need reliable and testable support for features. If it's enough to do #ifndef GRND_xxx/#define GRND_xxx and call getrandom() with these flags to detect support, it's basically 5 reliable lines of code to add to userland to make a warning disappear and/or to allow a system that previously failed to boot to now boot. So this gives strong incentive to userland to adopt the new API, provided there's a way for the developer to understand what's happening (which the warning does). If we do it right, all we'll hear are userland developers complaining that those stupid kernel developers have changed their API again and really don't know what they want. That will be a good sign that the warning flows back to them and that adoption is taking. And if the change is small enough, maybe it could make sense to backport it to stable versions to fix boot issues. With a testable feature it does make sense. Willy
