All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Yury Kotov <yury-kotov@yandex-team.ru>,
	Juan Quintela <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"open list:All patches CC here" <qemu-devel@nongnu.org>,
	yc-core@yandex-team.ru
Subject: Re: [Qemu-devel] [PATCH 0/3] Add 'inline-fd:' protocol for migration
Date: Fri, 12 Apr 2019 18:23:09 +0100	[thread overview]
Message-ID: <20190412172309.GF25308@redhat.com> (raw)
In-Reply-To: <fff20c68-d4db-3a56-ba39-dc487d6f80e5@redhat.com>

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".

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 :|

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	"open list:All patches CC here" <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Yury Kotov <yury-kotov@yandex-team.ru>,
	yc-core@yandex-team.ru, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] Add 'inline-fd:' protocol for migration
Date: Fri, 12 Apr 2019 18:23:09 +0100	[thread overview]
Message-ID: <20190412172309.GF25308@redhat.com> (raw)
Message-ID: <20190412172309.Qey6-kBtb0SdehC4L0k2UoIyk80npTC-Y5_r2ZSfWoA@z> (raw)
In-Reply-To: <fff20c68-d4db-3a56-ba39-dc487d6f80e5@redhat.com>

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".

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 :|


  reply	other threads:[~2019-04-12 17:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 12:20 [Qemu-devel] [PATCH 0/3] Add 'inline-fd:' protocol for migration Yury Kotov
2019-04-12 12:20 ` [Qemu-devel] [PATCH 1/3] monitor: Add monitor_recv_fd function to work with sent fds Yury Kotov
2019-04-12 12:20 ` [Qemu-devel] [PATCH 2/3] migration: Add inline-fd protocol Yury Kotov
2019-04-12 12:20 ` [Qemu-devel] [PATCH 3/3] migration-test: Add a test for inline_fd protocol Yury Kotov
2019-04-12 17:13 ` [Qemu-devel] [PATCH 0/3] Add 'inline-fd:' protocol for migration Eric Blake
2019-04-12 17:23   ` Daniel P. Berrangé [this message]
2019-04-12 17:23     ` Daniel P. Berrangé
2019-04-12 18:49     ` Dr. David Alan Gilbert
2019-04-12 18:49       ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190412172309.GF25308@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thuth@redhat.com \
    --cc=yc-core@yandex-team.ru \
    --cc=yury-kotov@yandex-team.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.