Anthony Liguori wrote: > I'm all for doing things incrementally but there has to be a big picture > that the incremental bit fits into otherwise you end up with a bunch of > random features that don't work together well.
Well, if you just add stuff without ever changing anything that went before, of course. > Honestly, I'd strongly suggest splitting the reconnect logic out of the > series when resubmitting. IMO the RNG stuff is worthless without the reconnect logic. You cant have a machine in a production environment that just stops getting entropy forever when you (say) restart the EGD, perhaps during a package update. Or when someone unplugs the entropy source temporarily or something like that. > I think it's just too hacky with too weak of > a justification. If you really want this functionality, we can discuss > the right approach for doing it but it's gotta be done in a way that's > not introducing a one-off case just for the random number generator. I dont think its a case of 'really want' as much as 'its completely essential' :-) I still think that unless there are any other use cases, theres not much to discuss - The code is already generic to some degree - it notifies users, and its got a configurable delay. What else do we need? I implemented it generically rather than stuff it into the virtio-rng driver *because* I didnt think a dedicated version of it was the right way to go, but without some other use cases, I cant see what good there is in bikeshedding over this? -Ian
