Hardly; the first version of this patch series was from August 2019 (which is before the brouhaha caused by ext4 getting optimized and causing boot-time hangs f

Hardly; the first version of this patch series was from August 2019 (which is before the brouhaha caused by ext4 getting optimized and causing boot-time hangs for some combinations of hardware plus some versions of systemd/udev), and the second version was from September 2019. In the second version, Andy mentioned he wanted to make further changes, and so I waited for it to be complete. I had also discussed making this change with Linus in Lisbon at the Kernel Summit last year. So this was a very well considered change that had been pending for a while, and it predates the whole getrandom boot hang issue last September. I don't like making changes like this without careful consideration. The strongest argument in favor of not making this change was there are some (misguided) PCI compliance labs which had interpreted the PCI spec as requiring /dev/random, and changing /dev/random to work like getrandom(2) might cause problems for some enterprise companies that need PCI compliance. However, the counter-argument is that it wasn't clear that the PCI compliance labs somehow thought that /dev/random was better than getrandom(2); it was just as likely they were so clueless that they hadn't even heard about getrandom(2). And if they were that clueless, they probably wouldn't notice that /dev/random had changed. If they really did want TrueRandom (whatever the hell that means; can you guarantee your equipment wasn't intercepted by the NSA while it was in-transit to the data center?) then the companies probably really should be using some real hardware random number generator, since on some VM's with virtio-rng, /dev/random on the guest was simply getting information piped from /dev/urandom on the host system --- and apparently that was Okey-Dokey with the PCI labs. Derp derp derpity derp....