On Wed, Nov 13, 2013 at 10:19 PM, Kevin Wolf <kw...@redhat.com> wrote: > Am 13.11.2013 um 11:29 hat Fam Zheng geschrieben: >> We have multiple dirty bitmaps in BDS now, switch QAPI to allow query >> it (BlockInfo.dirty_bitmaps), and also drop old BlockInfo.dirty. >> >> Signed-off-by: Fam Zheng <f...@redhat.com> > >> diff --git a/qapi-schema.json b/qapi-schema.json >> index 81a375b..931d710 100644 >> --- a/qapi-schema.json >> +++ b/qapi-schema.json >> @@ -948,8 +948,8 @@ >> # @tray_open: #optional True if the device has a tray and it is open >> # (only present if removable is true) >> # >> -# @dirty: #optional dirty bitmap information (only present if the dirty >> -# bitmap is enabled) >> +# @dirty-bitmaps: #optional dirty bitmaps information (only present if the >> +# driver has one or more dirty bitmaps) >> # >> # @io-status: #optional @BlockDeviceIoStatus. Only present if the device >> # supports it and the VM is configured to stop on errors >> @@ -963,7 +963,7 @@ >> 'data': {'device': 'str', 'type': 'str', 'removable': 'bool', >> 'locked': 'bool', '*inserted': 'BlockDeviceInfo', >> '*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatus', >> - '*dirty': 'BlockDirtyInfo' } } >> + '*dirty-bitmaps': ['BlockDirtyInfo'] } } >> >> ## >> # @query-block: > > I believe this is of limited use; if you ever have more than one dirty > bitmap, we're lacking information to associate it with the job it > belongs to. One option would be to extend BlockDirtyInfo to indicate > this, but another might be to actually extend other commands like > query-block-jobs to return information on the dirty bitmap associated > with a specific job. > > I've applied it to block-next anyway, we still have some time to > reconsider for 1.8. >
Another case for this may be user enabled external dirty bitmap, which could be standalone from any block job. E.g. when we introduce a QMP command like: block-new-dirty-bitmap device=foo file=bar.bitmap This could be some code in block.c, could be a block job (really necessary?), or a block filter. I'm not sure... Fam