diff options
author | Daniel P. Berrange <berrange@redhat.com> | 2017-12-22 11:04:30 +0000 |
---|---|---|
committer | Daniel P. Berrangé <berrange@redhat.com> | 2018-03-13 18:06:06 +0000 |
commit | 1723d6b1cfe6572881f578bce3aa25185b81b148 (patch) | |
tree | 44dae53ec8493fe6f05756b36fcdf86c38693939 /HACKING | |
parent | 30bdb3c56ddd911ab2b1629faa4ce6e883b80e2a (diff) |
sockets: allow SocketAddress 'fd' to reference numeric file descriptors
The SocketAddress 'fd' kind accepts the name of a file descriptor passed
to the monitor with the 'getfd' command. This makes it impossible to use
the 'fd' kind in cases where a monitor is not available. This can apply in
handling command line argv at startup, or simply if internal code wants to
use SocketAddress and pass a numeric FD it has acquired from elsewhere.
Fortunately the 'getfd' command mandated that the FD names must not start
with a leading digit. We can thus safely extend semantics of the
SocketAddress 'fd' kind, to allow a purely numeric name to reference an
file descriptor that QEMU already has open. There will be restrictions on
when each kind can be used.
In codepaths where we are handling a monitor command (ie cur_mon != NULL),
we will only support use of named file descriptors as before. Use of FD
numbers is still not permitted for monitor commands.
In codepaths where we are not handling a monitor command (ie cur_mon ==
NULL), we will not support named file descriptors. Instead we can reference
FD numers explicitly. This allows the app spawning QEMU to intentionally
"leak" a pre-opened socket to QEMU and reference that in a SocketAddress
definition, or for code inside QEMU to pass pre-opened FDs around.
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Diffstat (limited to 'HACKING')
0 files changed, 0 insertions, 0 deletions