On Tue, Apr 24, 2012 at 8:31 PM, Luiz Capitulino <lcapitul...@redhat.com> wrote: > On Tue, 24 Apr 2012 14:53:54 +0100 > Stefan Hajnoczi <stefa...@linux.vnet.ibm.com> wrote: > >> Eric Blake raised concerns about the inability to start block jobs with a >> speed >> limit. Current the user needs to follow up the block-stream command with >> block-job-set-speed. There is a window of time while the new block job is >> running but block-job-set-speed has not been processed yet. >> >> This series adds an optional 'speed' parameter to block-stream so streaming >> can >> be started with a speed limit that takes effect immediately. >> >> For consistency it also renames the block-job-set-speed parameter from >> 'value' >> to 'speed'. This is externally visible, but this API has not been in a QEMU >> release yet so we can still do this. >> >> I considered several other approaches, including adding a >> default_block_job_speed field to BlockDriverState but ultimately the cleanest >> solution is to pass in a speed parameter on job creation. This way we do not >> change semantics of existing commands, we only add an optional parameter. We >> also do not need to add state to BlockDriverState, which is already huge and >> messy. >> >> The last patch fixes a small bug I found in qemu-iotests 030. > > Looks good to me. Is this expected to go through my tree?
It probably should. The "block:" prefix to this series would probably best be "qmp:" :). I will send out a v3 including the cleanups that have been suggested. Stefan
