From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNeBf-0002Qj-EV for qemu-devel@nongnu.org; Mon, 25 Jan 2016 05:16:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNeBa-0008KN-Ed for qemu-devel@nongnu.org; Mon, 25 Jan 2016 05:15:55 -0500 Received: from mx2.parallels.com ([199.115.105.18]:35203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNeBa-0008K3-7m for qemu-devel@nongnu.org; Mon, 25 Jan 2016 05:15:50 -0500 Message-ID: <56A5F5BD.40501@virtuozzo.com> Date: Mon, 25 Jan 2016 13:15:25 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1452517517-3953-1-git-send-email-vsementsov@virtuozzo.com> <56981C60.9020005@redhat.com> <56982EA9.6030602@redhat.com> <569A4E71.5010004@virtuozzo.com> <569D18CE.5070104@redhat.com> <569D5648.6030605@redhat.com> <569DFA95.5020409@virtuozzo.com> <20160119172923.GG4579@noname.redhat.com> In-Reply-To: <20160119172923.GG4579@noname.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7] spec: add qcow2 bitmaps extension specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: famz@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, John Snow On 19.01.2016 20:29, Kevin Wolf wrote: > Am 19.01.2016 um 09:57 hat Vladimir Sementsov-Ogievskiy geschrieben: >> On 19.01.2016 00:16, Eric Blake wrote: >>> preserving semantics of those extra_data bytes). We >>> have enough room for future extension, and that's good e >> Ok, so, what should go to the spec? Current wording is ok? Just >> delete "Type-specific": >> >> + >> + 20 - 23: extra_data_size >> + Size of type-specific extra data. >> + >> + For now, as no extra data is defined, extra_data_size is >> + reserved and must be zero. >> + >> + variable: Extra data for the bitmap. > Please be explicit that if extra_data_size is non-zero, the bitmap must > not be used (i.e. specify the incompatible-feature-bit-like behaviour). It is not enough. If there are some unknown extra data, then just ignoring this bitmap may lead to its inconsistency. So, if it is non-zero, the whole image should not be written. (real incompatible-feature-bit behavior). > > Kevin -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.