On 2/13/19 5:23 PM, John Snow wrote: > Simply move the big status enum comment block to above the status > function, and document it as being deprecated. The whole confusing > block can get deleted in three releases time. > > Signed-off-by: John Snow <jsnow@xxxxxxxxxx> > --- > block/dirty-bitmap.c | 36 +++++++++++++++++++----------------- > 1 file changed, 19 insertions(+), 17 deletions(-) > > -/* Called with BQL taken. */ > +/** > + * bdrv_dirty_bitmap_status: This API is now deprecated. > + * Called with BQL taken. > + * > + * A BdrvDirtyBitmap can be in four possible user-visible states: > + * (1) Active: successor is NULL, and disabled is false: full r/w mode > + * (2) Disabled: successor is NULL, and disabled is true: qualified r/w mode, > + * guest writes are dropped, but monitor writes are possible, > + * through commands like merge and clear. > + * (3) Frozen: successor is not NULL. > + * A frozen bitmap cannot be renamed, deleted, cleared, set, > + * enabled, merged to, etc. A frozen bitmap can only abdicate() > + * or reclaim(). > + * In this state, the anonymous successor bitmap may be either > + * Active and recording writes from the guest (e.g. backup jobs), > + * but it can be Disabled and not recording writes. Pre-existing due to code motion, but you could improve the grammar with s/but/or/ > + * (4) Locked: Whether Active or Disabled, the user cannot modify this bitmap > + * in any way from the monitor. > + */ Reviewed-by: Eric Blake <eblake@xxxxxxxxxx> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
