[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 09/11] char-socket: Fix qemu_chr_socket_address() for abstrac
From: |
Markus Armbruster |
Subject: |
Re: [PATCH 09/11] char-socket: Fix qemu_chr_socket_address() for abstract sockets |
Date: |
Fri, 30 Oct 2020 10:09:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Eric Blake <eblake@redhat.com> writes:
> On 10/29/20 8:38 AM, Markus Armbruster wrote:
>> Commit 776b97d360 "qemu-sockets: add abstract UNIX domain socket
>> support" neglected to update qemu_chr_socket_address(). It shows
>> shows neither @abstract nor @tight. Fix that.
>>
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>> chardev/char-socket.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>
>> +++ b/chardev/char-socket.c
>> @@ -443,10 +443,18 @@ static char *qemu_chr_socket_address(SocketChardev *s,
>> const char *prefix)
>> s->is_listen ? ",server" : "");
>> break;
>> case SOCKET_ADDRESS_TYPE_UNIX:
>> - return g_strdup_printf("%sunix:%s%s", prefix,
>> + {
>> + UnixSocketAddress *sa = &s->addr->u.q_unix;
>> +
>> + return g_strdup_printf("%sunix:%s%s%s%s", prefix,
>> s->addr->u.q_unix.path,
>> + sa->has_abstract && sa->abstract
>> + ? ",abstract" : "",
>> + sa->has_tight && sa->tight
>> + ? ",tight" : "",
>
> Why are we appending ',tight' when it is not abstract? tight only makes
> a difference for abstract sockets, so omitting it for normal sockets
> makes more sense.
We don't bother to reject @tight when @abstract is false. Not bothering
to suppress it here is consistently careless.
I'm trying to make this pig less wrong, I'm not trying to make it less
ugly.
> Or put another way, why are we using 2 bools to represent three sensible
> states, instead of a single 3-state enum?
Because the QAPI interface got merged without proper review by the QAPI
maintainers?
>> s->is_listen ? ",server" : "");
>> break;
>> + }
>> case SOCKET_ADDRESS_TYPE_FD:
>> return g_strdup_printf("%sfd:%s%s", prefix, s->addr->u.fd.str,
>> s->is_listen ? ",server" : "");
>>