Re: [Qemu-devel] [PATCH 02/16] qemu-char: Allow a chardev to reconnect if disconnected

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 13, 2013 at 02:51:39PM -0600, Corey Minyard wrote:
> On 11/13/2013 02:55 AM, Gerd Hoffmann wrote:
> >   Hi,
> >
> >> Allow a socket that connects to reconnect on a periodic basis if it
> >> fails to connect at startup or if the connection drops while in use.
> >> +    chr->backend = i;
> >> +    chr->recon_time = qemu_opt_get_number(opts, "reconnect", 0);
> >> +    if (chr->recon_time) {
> >> +        if (strcmp(qemu_opt_get(opts, "backend"), "socket") != 0) {
> >> +            g_free(chr);
> >> +            fprintf(stderr, "chardev: reconnect only supported on sockets\n");
> >> +            return NULL;
> >> +        }
> > I think it would work *much* better to just add a "chr_reconnect"
> > function pointer to CharDriverState.  You don't need patch #1 then.
> > Also it avoids backend-specific bits in generic code.  Generic code just
> > checks if chr->chr_reconnect exists to figure whenever reconnect is
> > supported or not.  And the socket backend can set chr_reconnect for
> > client sockets only.
> 
> I was trying for something more generic than one that just applies to
> socket devices.  It may not be good for server sockets, but it might be
> useful for ptys and hotplug devices.  Looking at the code, ptys already
> has its own code that does something similar; that could be pulled out
> and replaced with the generic code.
> 
> Also, IMHO allocating the chardev in each back end is not optimal.  It
> breaks layering.  Plus patch #1 has a net reduction in lines of code
> because it pulls out all the allocations and does it in one place.
> 
> Thanks,
> 
> -corey

I guess this was just one suggestion.

What Gerd is asking for here is that we avoid
code like

	strcmp(qemu_opt_get(opts, "backend"), "socket")

in generic code, instead making a backend report
reconnect support.
This sounds reasonable, does it not?