qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qemu-char: Convert socket char backend to parse


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH] qemu-char: Convert socket char backend to parse/kind
Date: Mon, 30 Jun 2014 12:57:54 +0200

On Mo, 2014-06-30 at 11:33 +0100, Peter Maydell wrote:
> On 30 June 2014 11:23, Gerd Hoffmann <address@hidden> wrote:
> >   Hi,
> >
> >> >  * The old qemu_chr_open_socket() has an
> >> >    "if (!is_waitconnect)
> >> >        qemu_set_nonblock(fd);
> >> >    which the QMP char-open codepath has never had. Does this matter?
> >> >    Which of the two code paths was correct?
> >>
> >> Gerd?
> >
> > IIRC the socket is put into non-blocking mode anyway by the qemu socket
> > helper functions.
> 
> In that case is qemu_chr_open_socket_fd() incorrect
> in marking the socket as nonblocking in the
> is_listen && is_waitconnect case?

Honestly I think the whole waitconnect stuff should be ripped out.
Obvious problem is backward compatibility.  But maybe not because nobody
uses it anyway.  Anyone out there using chardev server sockets without
'nowait' option?

waitconnect means "go into server mode, wait for a client to connect,
then unpause the guest".  Which handles one special case of the generic
"start qemu with -S, connect everything, then sent 'cont' to monitor"
libvirt is doing.

IIRC "wait for client to connect" is a blocking accept() call.  Which
you certainly don't want do in a qmp command handler.  So if we switch
over chardevs created via -chardev to use the qmp init code path too we
need some hackery to make '-chardev socket,wait,...' work without
introducing a blocking qmp command I suspect ...

cheers,
  Gerd





reply via email to

[Prev in Thread] Current Thread [Next in Thread]