Am Sun, Nov 06, 2022 at 02:50:42AM +0100 schrieb Jason A. Donenfeld: > Rather than calling add_device_randomness(), the add_early_randomness() > function should use add_hwgenerator_randomness(), so that the early > entropy can be potentially credited, which allows for the RNG to > initialize earlier without having to wait for the kthread to come up. We're already at device_initcall() level here, so that shouldn't be much of an additional delay. > Since we don't want to sleep from add_early_randomness(), we also > refactor the API a bit so that hw_random/core.c can do the sleep, this > time using the correct function, hwrng_msleep, rather than having > random.c awkwardly do it. Isn't this something you were quite hesistant about just recently[*]? | I was thinking the other day that under certain circumstances, it | would be nice if random.c could ask hwrng for more bytes NOW, rather | than waiting. With the code as it is currently, this could be | accomplished by having a completion event or something similar to | that. With your proposed change, now it's left up to the hwrng | interface to handle. | | That's not the end of the world, but it does mean we'd have to come up | with a patch down the line that exports a hwrng function saying, "stop | the delays and schedule the worker NOW". Now impossible, just more | complex, as now the state flow is split across two places. Wondering | if you have any thoughts about this. Thanks, Dominik [*] https://lore.kernel.org/lkml/CAHmME9rhunb05DEnc=UfGr8k9_LBi1NW2Hi0OsRbGwcCN2NzjQ@xxxxxxxxxxxxxx/
