Yes but what does initialized mean? Is that like an early bootup thing?

There isn't a guarantee of that.

It is the current implementation that it's only an early boot time thing, but it would make sense to revert to uninitialized in cases like is brought up in the patch series. That is when some event like vm rehydration means that existing entropy needs to be invalidated. On x86 you'll pretty much always have an hwrng when you have virtualization extensions, but that isn't true for other archs.

It's such a ridiculous API. What's the point of documenting a guarantee if there's officially speaking no guarantee? When I implemented getentropy() for cosmo libc, it'll actually issue three system calls in the best case on Linux to block signals while calling getrandom() because I've never trusted it.

But I still refuse to believe it's possible for a PRNG to block in a way where there's observable side-effects like EINTR. It's just too insane. There's no Linux architecture that does this when flags==0 && size<=256 and there never will be one, because that's a bug. Prove that it can happen and we shall patch the kernel to make it not happen.

I mean, if there isn't enough entropy yet to seed the kernel's PRNG (because say, you just resumed a VM image, and all entropy pools are invalidated), and you didn't specify that it's allowed to fail becuase you didn't specify non block, what is it supposed to do other than block and allow signals and thus potentially fail with EINTR?

I fail to see the bug here.

Why would you cut into an operation that's already measured milliseconds (vm image rehydration is one of the implementations of 'serverless') over a single syscall that's already built around the idea of blocking if it needs more time?

Yes, exactly.