Ian Molton wrote: > >You can configure any chardev to be a tcp client. I never do that though > >as I find it much more convenient to configure it as server. > > Perhaps thats because chardev clients are nearly useless right now > because they just die if the connection drops...
Which is why drops/missing server should be a QMP event + action, same as other triggers like disk full and watchdog trigger. I do not want my guests to continue running if they are configured to depend on Qemu entropy and it's not available. > Or are you suggesting that we create another type of chardev, thats > nearly like a socket, but speaks egd and can reconnect? That seems > hideous to me. Why hideous? An egd chardev is a good thing because you can then trivially use it as a random byte source for virtio-serial, isa-serial, pci-serial, custom-soc-serial, debug-port even :-), and anything else which might want random bytes as Gerd said. That's way more useful than restricting to virtio-rng, because most guests don't support virtio at all, but they can probably all take entropy from a serial-like device. Similarly the ability to connect to /dev/urandom directly, with the rate-limiting but no auto-reconnection, looking like a chardev in the same way, would make sense. Reconnection is not needed in this case - missing device should be an error at startup. Your idea for an 'egd line discipline' would need to look exactly like a chardev internally, or all the devices which might find it useful would have to be changed to know about line disciplines, or it just wouldn't be available as a random byte source to everything that uses a chardev - unnecessary limiting. There's nothing wrong with the egd chardev actually _being implemented_ like a line discipline on top of another chardev, with a chardev interface so everything can use it. In which case it's quite natural to expose the options as a user-visible chardev 'egd', defined to return random bytes on input and ignore output, which takes all the same options as 'socket' and actually uses a 'socket' chardev (passing along the options). (Is there any actual point in supporting egd over non-sockets?) I think rate-limiting is more generically useful as a 'line discipline'-like feature, to work with any chardev type. But it should then have properties governing incoming and outgoing rate limiting separately, which won't get much testing for the only imminent user which is input-only. > That way it wouldn't matter if it were a socket or anything else that > the data came in via, which is the case with the patch as I wrote it - > you can feed in EGD from a file, a socket, anything, and it just works. What's the point in feeding egd protocol from a file? If you want entropy from a file, it should probably be raw, not egd protocol. -- Jamie
