Am 25.04.2012 12:57, schrieb Stefan Hajnoczi: > 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.
If this is going to be merged through Luiz' tree, you can add an: Acked-by: Kevin Wolf <kw...@redhat.com>