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 <js...@redhat.com> > --- > 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 <ebl...@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
