From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40152 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5JHy-0003uO-IK for qemu-devel@nongnu.org; Mon, 11 Oct 2010 10:23:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5J6w-0005lF-Mz for qemu-devel@nongnu.org; Mon, 11 Oct 2010 10:12:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5J6w-0005l4-Gx for qemu-devel@nongnu.org; Mon, 11 Oct 2010 10:12:18 -0400 Message-ID: <4CB31B38.1050603@redhat.com> Date: Mon, 11 Oct 2010 16:12:08 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1286552914-27014-1-git-send-email-stefanha@linux.vnet.ibm.com> <1286552914-27014-4-git-send-email-stefanha@linux.vnet.ibm.com> <4CB18549.3020206@redhat.com> <20101011100954.GA4078@stefan-thinkpad.transitives.com> <4CB30B43.2040706@redhat.com> <20101011134241.GA5439@stefan-thinkpad.transitives.com> <4CB314C6.4040001@redhat.com> <20101011140637.GC5439@stefan-thinkpad.transitives.com> In-Reply-To: <20101011140637.GC5439@stefan-thinkpad.transitives.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Christoph Hellwig On 10/11/2010 04:06 PM, Stefan Hajnoczi wrote: > On Mon, Oct 11, 2010 at 03:44:38PM +0200, Avi Kivity wrote: > > On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote: > > >> > > >> A leak is acceptable (it won't grow; it's just an unused, incorrect > > >> freelist), but data corruption is not. > > > > > >The alternative is for the freelist to be a non-compat feature bit. > > >That means older QEMU binaries cannot use a QED image that has enabled > > >the freelist. > > > > For this one feature. What about others? > > Compat features that need to be in sync with the image state will either > require specific checks (e.g. checksum or shadow of the state) or they > need to be non-compat features and are not backwards compatible. > > I'm not opposing autoclear feature bits themselves, they are a neat > idea. However, they will initially have no users so is this something > we really want to carry? Hard to tell in advance. It seems like a simple feature with potential to make our lives easier in the future. Anything we develop in the next few months can be rolled back into the baseline, assuming we declare the format unstable while 0.14 is in development, so this is really about post 0.14 features. -- error compiling committee.c: too many arguments to function