Gerd Hoffmann <kra...@redhat.com> 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
degree.

> 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