qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 35/40] job: Add JOB_STATUS_CHANGE QMP event


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 35/40] job: Add JOB_STATUS_CHANGE QMP event
Date: Thu, 24 May 2018 10:36:24 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 24.05.2018 um 02:02 hat John Snow geschrieben:
> 
> 
> On 05/18/2018 09:21 AM, Kevin Wolf wrote:
> > This adds a QMP event that is emitted whenever a job transitions from
> > one status to another.
> > 
> > Signed-off-by: Kevin Wolf <address@hidden>
> 
> That's a lot of events, and a lot are redundant to what we already
> transmitted under block jobs; it also has the effect of making internal
> state changes explicit behavior that we're responsible for maintaining
> for external clients.
> 
> Is that what we want here?
> 
> (I mean, the answer is probably "Yes" because you're here writing the
> patch, but I was hoping to find your motivation.)

The state change is visible in query-jobs anyway, so allowing the client
to get events rather than polling query-jobs doesn't change the amount
of information that is exposed.

You're right that some of the events are redundant with existing block
job events, but that unavoidable because we can't send BLOCK_JOB_*
events for non-block jobs. And not sending JOB_* for block jobs would be
inconsistent.

The question that I was asking myself was just whether I'd literally
duplicate the existing events, just with s/BLOCK_JOB_/JOB_/, or whether
a single event with a status field can do. I think the latter is more
elegant (also because it can be implemented in a single place), even if
it is emitted a bit more often than strictly necessary.

Kevin



reply via email to

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