From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIuM0-0006Fu-T2 for qemu-devel@nongnu.org; Tue, 12 Jan 2016 03:31:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIuLw-0007fn-Pr for qemu-devel@nongnu.org; Tue, 12 Jan 2016 03:31:00 -0500 Received: from relay.parallels.com ([195.214.232.42]:45872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIuLw-0007eY-HD for qemu-devel@nongnu.org; Tue, 12 Jan 2016 03:30:56 -0500 Message-ID: <5694B9AE.6030108@virtuozzo.com> Date: Tue, 12 Jan 2016 11:30:38 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1450892961-6495-1-git-send-email-vsementsov@virtuozzo.com> <568AFD50.9030006@redhat.com> <56939E25.9000309@virtuozzo.com> <5693E14D.6000708@redhat.com> In-Reply-To: <5693E14D.6000708@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6] spec: add qcow2 bitmaps extension specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , qemu-devel@nongnu.org, Eric Blake Cc: kwolf@redhat.com, den@openvz.org, famz@redhat.com, stefanha@redhat.com, mreitz@redhat.com On 11.01.2016 20:07, John Snow wrote: > > On 01/11/2016 07:20 AM, Vladimir Sementsov-Ogievskiy wrote: >> Are you sure? What about creation\last change dates, file links, user >> data, etc? >> For now, formally, current "For now, as no extra data is defined, >> extra_data_size is reserved and must be zero." is equal to such table, >> but provides more flexibility for future.. > Oh, I see what you're trying to do. > > In this case, perhaps we need a versioning system for the type-specific > data? We won't be able to just add data arbitrarily, we need to change > some field somewhere. > > Maybe we can say something like... > > "If extra_data_size is 0, there is no type-specific data and the version > of that data layout is 0. If extra_data_size is non-zero, the first byte > of the type-specific-data must be a version number greater than 0 that > indicates the layout of the data to follow. > > For the Dirty Tracking bitmap type, only version 0 is currently valid." > > This way it's explicit that data *could* show up for dirty tracking in > the future, but currently it does not. > > --js It's ok for me. -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.