From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MbDCN-00068i-Nw
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 08:44:59 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MbDCH-00065Y-9F
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 08:44:58 -0400
Received: from [199.232.76.173] (port=32906 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MbDCG-00065D-Da
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 08:44:53 -0400
Received: from mx2.redhat.com ([66.187.237.31]:57992)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1MbDCF-0007C4-PB
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 08:44:52 -0400
Message-ID: <4A82B900.4070605@redhat.com>
Date: Wed, 12 Aug 2009 14:43:44 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] stacking the block layer
References: <B08B5C37-2804-4F24-9015-505D8A050D57@suse.de>
In-Reply-To: <B08B5C37-2804-4F24-9015-505D8A050D57@suse.de>
Content-Type: text/plain; charset=ISO-8859-1
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.gnu.org/pipermail/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: Alexander Graf <agraf@suse.de>
Cc: qemu-devel <qemu-devel@nongnu.org>

Alexander Graf schrieb:
> Hi list,
> 
> I just implemented dzip (seekable gzip) support and stumbled across a  
> major bummer in the block layer:
> 
> Formats can't be stacked.
> 
> So why do we have this restriction? From what I could tell, the  
> current code would just run into an endless loop, because the probe  
> function of the format we're trying to open triggers when trying to  
> open the underlying file.
> 
> Now that is a valid problem, but can't we just match that when opening  
> a file from say "qcow2" that we simply don't open backing files as  
> "qcow2" as well?
> 
> That way we could have qcow2 in dzip served via HTTP. At the end of  
> the day I also want to bring tar into the game, so we'd have qcow2  
> (format) in tar (format) in dzip (format) on HTTP (protocol).

No, this should actually be qcow2 (format) on tar (protocol) on dzip
(protocol) on http (protocol). I'm not sure though if you can specify
things like tar:dzip:http://... with the current block code but I don't
think you would run into the problem you described above with protocols.

Kevin