[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type
Date: Tue, 31 Jan 2017 09:18:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Gerd Hoffmann <address@hidden> writes:

>   Hi,
>> > It would be nice for this series to evolve to a generic QMP jobs series
>> > so that all background operations are visible to the client and a useful
>> > subset of management primitives can be implemented on a per-command
>> > basis.  Both live migration and existing block jobs could use this code
>> > so that we don't have multiple copies of the same infrastructure.
>> Indeed, but I would need to know what proposal or requirements the
>> block layer have here, and I would appreciate if they took time to
>> review mine. 
> Disclaimer:  Havn't looked into the qmp (especially block jobs) details
> too much.
> But I suspect we can have both, sharing most of the infrastructure,
> without too much effort.
> We have block jobs today.  Other areas in qemu can use that too.  So
> moving the jobs infrastructure from block to qmp level makes perfect
> sense to me.  Live migration and possibly others can start using it.

Yes.  When everything uses a generic job infrastructure instead of
rolling their own, things get simpler and more regular.  Should take
less code, too, although backward compatibility might thwart that to a

> And once we have that building async commands on top of that is probably
> easy.  It'll be just a primitive job which typically takes at most a few
> seconds to finish, has no ->cancel() callback and sends a different kind
> of completion notification ...

Plausible.  "Can" doesn't imply "should", of course.

Here's my current thinking:

* "Jobs" are a generalization of the ad hoc ways we do long-running
  activities, including "block jobs" and migration.  Having one general
  way to do a common, non-trivial thing makes sense.

* Block people have wanted "jobs" for quite a while.  The limitations of
  the existing "block jobs" are getting painful.

* Given this "jobs" concept, asynchronous commands are a degenerate case
  of it.  Whether they are a common case, I can't say, yet.  How the
  special case fits into the whole, and whether it's worth having needs
  to be evaluated.

* Like Gerd, I think we should do jobs first.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]