From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1ai5-0007QX-Qe for qemu-devel@nongnu.org; Mon, 30 Jun 2014 08:29:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1ahz-00089K-Lb for qemu-devel@nongnu.org; Mon, 30 Jun 2014 08:29:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1ahz-000897-C1 for qemu-devel@nongnu.org; Mon, 30 Jun 2014 08:29:19 -0400 Message-ID: <53B15814.5070106@redhat.com> Date: Mon, 30 Jun 2014 14:29:08 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1403297751-10379-1-git-send-email-peter.maydell@linaro.org> <87fviviydy.fsf@blackfin.pond.sub.org> <1404123796.24066.18.camel@nilsson.home.kraxel.org> <1404125874.24066.20.camel@nilsson.home.kraxel.org> In-Reply-To: <1404125874.24066.20.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu-char: Convert socket char backend to parse/kind List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann , Peter Maydell Cc: Patch Tracking , QEMU Developers , Markus Armbruster , Michael Roth , Luiz Capitulino , Anthony Liguori 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 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