[Qemu-block] Addressability of Block-jobs after bdrv_swap removal

[John Snow]

I have a question about how the device name of block jobs gets reported
now after the bdrv_swap removal patch.

Previously, it appears that the job stayed attached to the root-node (if
somewhat hackishly, apparently) so that we could at all stages report
our name without having to cache the device we started under.

However, since QMP commands refer to block-jobs solely through their
device name, do we have any cases post-removal where a job becomes
"unreachable" through its advertised name?

e.g.

the block-job-ready event uses the device name to advertise which job
has just converged. The user/client would then be responsible for
sending qmp-block-job-complete device=XXX to finish the job when desired.

I don't see one at a quick glance, but we don't have any cases where we
perform any graph manipulation before we expect the user to interface
with the job again, right?

(It's always done right at completion time, at least for drive-mirror.
Do any other jobs adjust the graph? If it's ever anything except right
before completion time, we may lose the ability to pause/resume,
set-speed, etc.)

Does this sound about right, or have I fatally misunderstood the situation?

--js


(post-script: I was thinking of adding a unique per-job ID that could be
reported alongside any events or errors where the job's device name was
reported, so that users could provide this ID to find the job. Each BB
would have a per-tree list of jobs with globally unique IDs, and
regardless of what node the job was currently attached to, we could
retrieve that job unambiguously. This would be useful if the above
question reveals an API problem, or more generally for multiple block
jobs where we'll need IDs to reference jobs anyway.)