Hi Jason,
Friendly ping?
IMHO Lennart, Alex and myself have raised (what I think to be) valid technical points regarding your concerns about your belief that the uevent mechanism is an ad-hoc mechanism that you don't consider viable.
Just to summarize:
* Upon VM clone, user space needs to adjust various components (DHCP leases, MAC addresses, etc.) that have nothing to do with PRNGs. * The path of exposing the VM clone event via vgetrandom() (or any other interface of random.c) is simply wrong. The random subsystem is the natural component to inform about when cached entropy is stale. It should not be responsible for informing user space about VM clone events. IOW, "reseed your PRNGs" is not equivalent to "your VM has been cloned".
Given all this, it would help the discussion if you explained why you believe random.c should propagate VM clone events and how.
If you don't believe that, could you explain what is the problem with the proposed uevent mechanism? Personally, I agree with Lennart that VMGenID is a generic ACPI device built for exactly this purpose. VMGenID is not an "ad-hoc driver". It is a standard which is supported by most (all?) major VMMs out there today and its whole purpose is to deliver inside the VM a notification that it was cloned.
Cheers, Babis