From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lo0vr-0005R8-1E for qemu-devel@nongnu.org; Sun, 29 Mar 2009 15:44:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lo0vl-0005Qw-IB for qemu-devel@nongnu.org; Sun, 29 Mar 2009 15:44:33 -0400 Received: from [199.232.76.173] (port=56640 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lo0vl-0005Qt-D5 for qemu-devel@nongnu.org; Sun, 29 Mar 2009 15:44:29 -0400 Received: from yw-out-1718.google.com ([74.125.46.157]:3723) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lo0vl-00041Z-3L for qemu-devel@nongnu.org; Sun, 29 Mar 2009 15:44:29 -0400 Received: by yw-out-1718.google.com with SMTP id 9so1038053ywk.82 for ; Sun, 29 Mar 2009 12:44:28 -0700 (PDT) Message-ID: <49CFCF9A.9020903@codemonkey.ws> Date: Sun, 29 Mar 2009 14:44:26 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [6907] Introducing qcow2 extensions (Uri Lublin) References: <49CE7352.1050800@redhat.com> <49CECB28.30306@codemonkey.ws> <49CF0AE7.4010500@redhat.com> In-Reply-To: <49CF0AE7.4010500@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: uri Lublin Avi Kivity wrote: > Anthony Liguori wrote: >>> We should introduce a notion of compatible vs. incompatible extensions. >>> >>> A compatible extension my be ignored by the qcow2 code if it does >>> not understand the magic number. An incompatible extension causes >>> an abort. This allows both more flexibility in how we can change >>> the file format. I believe ext* does the same thing. >> >> I was assuming that all extensions would be compatible. I don't like >> the idea of having qcow2 files floating around that require specific >> version of QEMU. >> >> For that, we should just bump to qcow3 (that's what versioning is >> for, right? :-). > > The problem is that you would need to bump the version each time you > made an incompatible change. We'd end up with qcow4351 very quickly. > > One option is to declare qcow3 as qcow2 + all incompatible extensions > just before 0.11. Another is to require explicit user action to > enable an incompatible option. If you did that, you could expect only > to upgrade qemu, not degrade, but that's a reasonable assumption in > many scenarios. Well what sort of incompatible extensions are we talking about? Are there things being kicked around? Regards, Anthony Liguori