Il 30/06/2014 14:33, Peter Maydell ha scritto:
>
> It's unnecessary. tcp_chr_accept calls tcp_chr_add_client, which takes care
> of that. But it doesn't hurt either.
I think the tcp_chr_accept->tcp_chr_add_client->set_nonblock
is marking the new fd returned from accept() as nonblocking.
The ca
On 30 June 2014 13:29, Paolo Bonzini wrote:
> Il 30/06/2014 12:57, Gerd Hoffmann ha scritto:
>> On Mo, 2014-06-30 at 11:33 +0100, Peter Maydell wrote:
>>> In that case is qemu_chr_open_socket_fd() incorrect
>>> in marking the socket as nonblocking in the
>>> is_listen && is_waitconnect case?
>
>
>
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 neve
On 30 June 2014 11:57, Gerd Hoffmann wrote:
> 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 '-chard
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 thi
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
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 anywa
On 23 June 2014 13:49, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> Convert the socket char backend to the new style QAPI framework;
>> this allows it to return an Error ** to callers who might not
>> want it to print directly about socket failures.
>>
>> Signed-off-by: Peter Maydell
>>
Peter Maydell writes:
> Convert the socket char backend to the new style QAPI framework;
> this allows it to return an Error ** to callers who might not
> want it to print directly about socket failures.
>
> Signed-off-by: Peter Maydell
> ---
> I'm not 100% sure I have this correct -- review fro
Convert the socket char backend to the new style QAPI framework;
this allows it to return an Error ** to callers who might not
want it to print directly about socket failures.
Signed-off-by: Peter Maydell
---
I'm not 100% sure I have this correct -- review from somebody
who understands the char b
10 matches
Mail list logo
