Am 18.05.2018 um 20:22 hat Eric Blake geschrieben: > On 05/18/2018 08:21 AM, Kevin Wolf wrote: > > This adds a minimal query-jobs implementation that shouldn't pose many > > design questions. It can later be extended to expose more information, > > and especially job-specific information. > > > > Signed-off-by: Kevin Wolf <kw...@redhat.com> > > --- > > qapi/job.json | 45 +++++++++++++++++++++++++++++++++++++++++++++ > > include/qemu/job.h | 3 +++ > > job-qmp.c | 54 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > job.c | 2 +- > > 4 files changed, 103 insertions(+), 1 deletion(-) > > > > > +## > > +# @JobInfo: > > +# > > +# Information about a job. > > +# > > +# @id: The job identifier > > > +## > > +{ 'struct': 'JobInfo', > > + 'data': { 'id': 'str', 'type': 'JobType', 'status': 'JobStatus', > > + 'current-progress': 'int', 'total-progress': 'int', > > + '*error': 'str' } } > > Is it worth exposing whether a job is auto-finalize and auto-complete? Goes > back to the issue of whether clients of the new job API would ever want/need > to rely on the auto- features; while clients of the old blockjob API that > get the auto- features by default will never be calling the new query-jobs > command.
There are probably more fields that could be exposed. For most of them, it's not obvious whether we want to expose them, so I went for the minimal useful information here. We can always add more information to a query command; but we can't take information away later if it turns out that exposing it was a bad idea. Kevin