aboutsummaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorDaniel P. Berrange <berrange@redhat.com>2017-12-22 11:04:30 +0000
committerDaniel P. Berrangé <berrange@redhat.com>2018-03-13 18:06:06 +0000
commit1723d6b1cfe6572881f578bce3aa25185b81b148 (patch)
tree44dae53ec8493fe6f05756b36fcdf86c38693939 /HACKING
parent30bdb3c56ddd911ab2b1629faa4ce6e883b80e2a (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