* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Fri, Apr 12, 2019 at 12:13:51PM -0500, Eric Blake wrote: > > 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. > > Yeah I tend to agree - we use FD passing extensively across QMP/HMP > and all these commands are written to interact with "getfd". I think > it would be a step backwards to introduce a special case with > migration that doesn't use "getfd".
Yes, agreed - as you spotted passing fd's gets a bit hairy, and hence it's best to keep it to a few places. Lets figure out the right way of fixing the double-close you spotted rather than adding new schemes. Dave > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK