Hi, > > This patch is modified according to corey's patch. Some changes below: > > 1. IMO it's unnecessary that chardev reconnect if it fails to connect at > > startup. > > Qemu exit in this scene. In this way the patch does not change interface of > > chardev. > > It would be much more simple. > > I believe that it should not stop qemu if it fails at startup. > Otherwise you constrain the start order and you can prevent a server > from coming up because of a missing resource that may not be that > critical at the moment.
With reconnect being implemented (and active, guess we should add a option for it) it we might rethink this indeed. > With the current implementation, client sockets > really aren't that useful for a critical system. Reconnecting makes it > usable in a critical system. I consider client sockets not very useful at all, I always put my sockets into server mode. YMMV though. > > 2. I set the reconnect timer one second, just like pty. > > I'm not too picky about the time. A couple of things about this: Well, sockets and pty are different. pty is a local thing. sockets (at least tcp) goes out to the network. After each failed reconnect the time to retry should be increased a bit so you don't flood the non-responding server with connect requests. > With this patch, the default behavior changes to reconnect. That might > cause issues for some users. Adding a configurable timeout is easy if > you have to specify something on the command line, that's why I did it. Specifying the timeout (best with min+max) could enable reconnect at the same time, i.e. something like -chardev socket,host=1.2.3.4,port=5678,reconnect=1-300 would turn on reconnect, with 1 second min and 300 seconds (5min) max delay. cheers, Gerd
