[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
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.
- [Qemu-devel] [PATCH v2 24/25] qtest: add /qemu-qmp/screendump test, (continued)
- [Qemu-devel] [PATCH v2 24/25] qtest: add /qemu-qmp/screendump test, Marc-André Lureau, 2017/01/18
- [Qemu-devel] [PATCH v2 25/25] qmp: move json-message-parser and check to QmpClient, Marc-André Lureau, 2017/01/18
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, no-reply, 2017/01/18
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Stefan Hajnoczi, 2017/01/23
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Marc-André Lureau, 2017/01/23
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Stefan Hajnoczi, 2017/01/24
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Marc-André Lureau, 2017/01/24
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Stefan Hajnoczi, 2017/01/30
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Marc-André Lureau, 2017/01/30
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Gerd Hoffmann, 2017/01/31
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type,
Markus Armbruster <=
Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Markus Armbruster, 2017/01/25