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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 30/06/2014 12:57, Gerd Hoffmann ha scritto:
> On Mo, 2014-06-30 at 11:33 +0100, Peter Maydell wrote:
>> On 30 June 2014 11:23, Gerd Hoffmann <kraxel@redhat.com> 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?

It's unnecessary.  tcp_chr_accept calls tcp_chr_add_client, which takes 
care of that.  But it doesn't hurt either.

> 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.

I agree you don't want to do it, but then... just don't do it. :)  We 
can leave in waitconnect, and leave it blocking.  QMP clients simply 
shouldn't use it, but if they do it's not our fault.

In fact, ChardevSocket.wait defaults to false (unlike the command-line 
counterpart).

Paolo