From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=45991 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ot6fv-0003Ji-8P
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 18:30:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Ot6ft-0004SH-1Q
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 18:29:58 -0400
Received: from mail-gx0-f173.google.com ([209.85.161.173]:34309)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Ot6fs-0004S6-Un
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 18:29:56 -0400
Received: by gxk26 with SMTP id 26so2557686gxk.4
	for <qemu-devel@nongnu.org>; Tue, 07 Sep 2010 15:29:56 -0700 (PDT)
Message-ID: <4C86BCE1.9030006@codemonkey.ws>
Date: Tue, 07 Sep 2010 17:29:53 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com>	<4C84E738.3020802@codemonkey.ws>
	<4C865187.6090508@redhat.com>	<4C86645F.8060005@codemonkey.ws>
	<20100907213524.GA17980@lst.de>
In-Reply-To: <20100907213524.GA17980@lst.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>

On 09/07/2010 04:35 PM, Christoph Hellwig wrote:
> On Tue, Sep 07, 2010 at 11:12:15AM -0500, Anthony Liguori wrote:
>    
>> IOW, what are valid values for backing_fmt?  "raw" and "qed" are obvious
>> but what does it mean from a formal specification perspective to have
>> "vmdk"?  Is that VMDK v3 or v4, what if there's a v5?
>>      
> It might be better to just use a uint16_t field for the backing format,
> where each valid format gets a bit position assigned.  For now just raw,
> qed and qcow2 would be enough.
>    

If it were just one bit for just raw or not raw, wouldn't that be enough?

Everything that isn't raw can be probed reliably so we really only need 
to distinguish between things that are probe-able and things that are 
not probe-able.

Regards,

Anthony Liguori