[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Who / what uses QMP command add_client?
From: |
Markus Armbruster |
Subject: |
Re: Who / what uses QMP command add_client? |
Date: |
Wed, 30 Nov 2022 13:43:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Marc-André Lureau <marcandre.lureau@redhat.com> writes:
> Hi
>
> On Tue, Nov 29, 2022 at 6:55 PM Markus Armbruster <armbru@redhat.com> wrote:
>
>> QMP command add_client's schema:
>>
>> ##
>> # @add_client:
>> #
>> # Allow client connections for VNC, Spice and socket based
>> # character devices to be passed in to QEMU via SCM_RIGHTS.
>> #
>> # @protocol: protocol name. Valid names are "vnc", "spice",
>> "@dbus-display" or
>> # the name of a character device (eg. from -chardev id=XXXX)
>> #
>> # @fdname: file descriptor name previously passed via 'getfd' command
>> #
>> # @skipauth: whether to skip authentication. Only applies
>> # to "vnc" and "spice" protocols
>> #
>> # @tls: whether to perform TLS. Only applies to the "spice"
>> # protocol
>> #
>> # Returns: nothing on success.
>> #
>> # Since: 0.14
>> #
>> # Example:
>> #
>> # -> { "execute": "add_client", "arguments": { "protocol": "vnc",
>> # "fdname": "myclient" } }
>> # <- { "return": {} }
>> #
>> ##
>> { 'command': 'add_client',
>> 'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
>> '*tls': 'bool' } }
>>
>> Spot the design flaw!
>>
>> It's overloaded @protocol. Two issues.
>>
>> One, character device IDs "vnc", "spice", "@dbus-display" don't work
>> here. If we ever add another protocol, we make another device ID not
>> work. Perhaps this is why Marc-André chose "@dbus-display", which
>> otherwise looks like a typo :)
>>
>
> That's right, I tried to avoid conflicting with chardev ID namespace. IDs
> can't start with '@'.
>
> btw, I have a few patches pending to extend add_client for windows sockets.
>
> I also have patches to check if fds are actually sockets, since that
> command doesn't make much sense with other fds.
>
>
>> Two, introspection can't tell us what protocols are supported.
>
> Hmm, not really a big deal I suppose. You would have both compile-time and
> run-time config. There are other means to introspect the display protocol,
> like query-vnc or query-spice. I thought I had something covering dbus as
> well, but I can't find it, I'll look at it.
Defeating introspection like this is careless design. I agree this one
is no big deal in practice.
> Let me know if you plan to touch that command, it will likely conflict with
> my work. I plan to submit it soon after the release, but I might do it
> earlier.
I looked at the command only because I'm trying to move crap out of
monitor/.
For PCI, that's "[PATCH 00/12] pci: Move and clean up monitor command
code".
add_client is a bit awkward. It's in qapi/misc.json and
monitor/qmp-cmds.c. If it was only about VNC and Spice, I'd move it to
qapi/ui.json and ui/. If it was only about socket character devices, to
qapi/char.json and char/. But it's both. Unless we pick one of the two
arbitrarily, it's stuck in monitor/.