On 12/21/2017 10:49 AM, Markus Armbruster wrote:
QAPI schema review only.
@@ -123,10 +124,16 @@
#
# @unix: Unix domain socket
#
+# @vsock: VSOCK socket
+#
+# @fd: socket file descriptor passed over monitor
+#
Indepedent doc fix. I'd put it in a separate patch.
Missed in v2, so we still need that.
One inaccuracy: @fd is *not* a file descriptor, it's the *name* of a
file descriptor. Please fix.
+# @fdset: socket file descriptor passed via CLI (since 2.12)
+#
I gather we have to ways to pass file descriptors. One way identifies
them by name (member @fd), the other by numeric ID (member @fdset).
Yes, sort of.
0. This is disgusting. Is there any way to unify the two, and deprecate
the loser (hopefully the numeric one)?
v2 went with the numeric one for the CLI, as it is less verbose.
1. What makes the second one a *set*?
We have two existing mechanisms for fd passing:
a) HMP and QMP have the older 'getfd' command since 0.14, which
associates a single fd (via SCM_RIGHTS) with a name (which cannot start
with a digit). This does not scale - every command that wants to use an
fd like this has to be updated to take an explicit fd argument; and you
can't alter permissions on the fd after the fact.
b) QMP added the newer 'add-fd' in 1.2, which allows the association of
multiple fds (via SCM_RIGHTS) with a set number (the set is then
accessed via the magic prefix /dev/fdset/NNN. This was also exposed via
the command line, via '--add-fd', at the same time. It also scales
better, in that any command that already takes a filename now operates
on fdsets as needed; also, you can associate multiple fds to the set
(one that is read-only, another that is read-write), and qemu will
alternate between fds according to permissions needed at the time.
New code targetting QMP should use only 'add-fd'; particularly since
-addfd is the only version that works via CLI, even if there is only one
fd in the set. But it is more verbose, so having CLI shorthand that
takes just an fd number is sometimes acceptable.
2. What ties the second one to the CLI? Accidents of implementation or
something deeper?
At this point, more history than anything else.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
