From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCvt7-0004aa-Nc for qemu-devel@nongnu.org; Wed, 17 Dec 2008 07:52:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCvt6-0004Yf-DX for qemu-devel@nongnu.org; Wed, 17 Dec 2008 07:52:29 -0500 Received: from [199.232.76.173] (port=33233 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCvt6-0004YQ-93 for qemu-devel@nongnu.org; Wed, 17 Dec 2008 07:52:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:55456) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCvt5-0001HO-Ia for qemu-devel@nongnu.org; Wed, 17 Dec 2008 07:52:27 -0500 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 29E80477CB for ; Wed, 17 Dec 2008 13:52:24 +0100 (CET) Message-ID: <4948F722.9090303@suse.de> Date: Wed, 17 Dec 2008 13:57:06 +0100 From: Kevin Wolf 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> <4947A52B.50301@redhat.com> In-Reply-To: <4947A52B.50301@redhat.com> Content-Type: text/plain; charset=UTF-8 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 Shahar Frank schrieb: > 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 ;-) I think I'm not really decided on that one. For me, the most important thing is that you don't force users to rely on guessing. So while I slightly tend towards the first option, I also wouldn't be opposed to the second one. Kevin