From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVhso-0003rW-2R for qemu-devel@nongnu.org; Wed, 11 Mar 2015 10:45:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVhsh-00066N-Ns for qemu-devel@nongnu.org; Wed, 11 Mar 2015 10:45:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVhsh-00064W-Fg for qemu-devel@nongnu.org; Wed, 11 Mar 2015 10:45:07 -0400 Message-ID: <550054F0.9060906@redhat.com> Date: Wed, 11 Mar 2015 10:45:04 -0400 From: John Snow MIME-Version: 1.0 References: <1425338403-16138-1-git-send-email-jsnow@redhat.com> <1425338403-16138-2-git-send-email-jsnow@redhat.com> <20150311134341.GE10493@stefanha-thinkpad.redhat.com> <55004EE9.8010302@redhat.com> <55005477.7000006@redhat.com> In-Reply-To: <55005477.7000006@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Stefan Hajnoczi Cc: vladimir Sementsov-Ogievskiy , "famz >> Fam Zheng" , qemu-devel , "armbru >> Markus Armbruster" On 03/11/2015 10:43 AM, Eric Blake wrote: > On 03/11/2015 08:19 AM, John Snow wrote: >> >> >> On 03/11/2015 09:43 AM, Stefan Hajnoczi wrote: >>> On Mon, Mar 02, 2015 at 06:19:47PM -0500, John Snow wrote: >>>> +## Bitmap Modes >>>> + >>>> +* A Bitmap can be "enabled" (tracking writes, the default) or >>>> "disabled" >>>> +(read-only, I/O is ignored.) This state is currently only changed >>>> internally >>>> +for the purposes of migration, and otherwise remains enabled. >>> >>> From a QMP API perspective this information is not relevant. The >>> documentation is clearer without the concept of enabled/disabled. >>> >> >> Hm ... I suppose; If you want all mention of this gone from user view, I >> should actually remove this status field from the query, too. It is >> entirely possible to have a state where the bitmap is not frozen, but it >> is disabled (migration, perhaps others in the future?) so I left the >> status visible to the user for now. >> >> libvirt et al could likely rely on the migration status to know not to >> manipulate bitmaps, but having that status information directly in the >> bitmap didn't bother me. > > With a back-compat perspective, it's easier to hide the field now and > add it later if we discover that it would have been useful to expose, > than it is to expose it now and then have to support it forever even > though no one uses it. I'm not yet sure if libvirt can make use of > knowing whether a bitmap is frozen/disabled. > Makes sense. I suspect I will leave the frozen status there, though, because applying an operation to a frozen bitmap WILL result in an error, and it would be nice to be able to avoid that scenario instead of it being a hidden status that sometimes fails your commands. Granted, it is only currently in this status while it is being USED for a job, so it may not be mechanically useful...