On 2/18/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote: > 14.02.2019 2:23, John Snow wrote: >> Instead of implying a locked status, make it explicit. > > locked interferes with bitmap mutex, so may be better "qmp_locked state", but not sure. > I agree that "locked" has too many meanings, so in patch 5 I start using the term "busy" instead. >> Now, bitmaps in use by migration, NBD or backup operations >> are all treated the same way with the same code paths. >> >> Signed-off-by: John Snow <jsnow@xxxxxxxxxx> >> Reviewed-by: Eric Blake <eblake@xxxxxxxxxx> > > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxx> > > Hmm. Isn't it better to make successor-related staff unrelated to locking at all? Maybe -- but it doesn't make sense to allow users to modify bitmaps that have a successor because we know it's definitely busy. I'll take a further cleanup patch if you think it's better -- just be careful to make sure that any interface calls will work gracefully with a bitmap with a successor. > So, backup will call set_qmp_locked like others? And then do create_successor, > abdicate, reclaim, whatever it wants, and finally set_qmp_locked(false) ? > To make it work even more in the same path. But it may be done separately, if we > want. >
