From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCZS9-0005mR-Br for qemu-devel@nongnu.org; Tue, 16 Dec 2008 07:55:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCZS5-0005kj-8U for qemu-devel@nongnu.org; Tue, 16 Dec 2008 07:55:07 -0500 Received: from [199.232.76.173] (port=48583 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCZS4-0005kb-U1 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 07:55:05 -0500 Received: from mx2.redhat.com ([66.187.237.31]:38821) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCZS4-0005AG-F6 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 07:55:04 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBGCt35Y016778 for ; Tue, 16 Dec 2008 07:55:03 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBGCt2ZC025856 for ; Tue, 16 Dec 2008 07:55:03 -0500 Received: from [10.35.1.184] (dhcp-1-184.tlv.redhat.com [10.35.1.184]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBGCt1Oc020183 for ; Tue, 16 Dec 2008 07:55:02 -0500 Message-ID: <4947A52B.50301@redhat.com> Date: Tue, 16 Dec 2008 14:55:07 +0200 From: Shahar Frank MIME-Version: 1.0 Subject: Re: [Qemu-devel][PATCH] Qemu image over raw devices References: <246345442.373921229413849052.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <49477773.3060405@suse.de> <4947812C.7050806@redhat.com> <49479AB6.4050902@suse.de> In-Reply-To: <49479AB6.4050902@suse.de> 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 Kevin, Daniel, What do you think is the right thing to do here? Option one: 1. I can suggest a new extension mechanism for QCOW2 (it can be even backwards compatible) and store the backing file format there 2. I can add a flag to qemu-img create to force backing file format (that is stored in the above extension). Or: Option two: I can register qcow2 as a protocol and allow users to explicitly force qcow2 image logic. It is true that the ":" notation is still used, but as this notation is still required even for the drive option (vvfat, for example) it won't be the first to introduce it to the system. I have a feeling you both prefer option one ;-) Shahar