On 4/12/19 7:20 AM, Yury Kotov wrote: > Hi, > > I've added 'inline-fd:' proto to simplify migration to/from fd. > I thought about modifying the existing 'fd:' proto but I'm not sure it's a > good idea to change it's contract. > > Existing 'fd:' proto works with previously added fd by getfd or add-fd > commands. > If client doesn't want to work with this fd before or after migration then > it's > easier to send an fd with the migrate-* command. Also, client shouldn't > maintain > this fd.
While the sentiment of making it easier by having fewer QMP commands
might be worthwhile, I'm worried about whether this scales. Having just
a limited set of commands that take an fd over SCM rights, and every
other command wired to automagically work with existing named fds,
scales a lot easier than having to teach individual commands how to take
an fd inline.
At the very least, if we DO decide we like this, then I'd at least hope
that you made this addition introspectible (how can management learn
whether the 'inline-fd:' protocol is supported, and even more
importantly, which commands require an inline fd via SCM rights to be a
valid command based, especially if accepting or rejecting an inline fd
is conditional on other arguments to the command).
>
> Usage:
> { 'execute': 'migrate', 'arguments': { 'uri': 'inline-fd:' } }
> { 'execute': 'migrate-incoming', 'arguments': { 'uri': 'inline-fd:' } }
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
