From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUOMZ-0002W7-Hv for qemu-devel@nongnu.org; Mon, 11 Jan 2010 12:47:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUOMU-0002TV-Cs for qemu-devel@nongnu.org; Mon, 11 Jan 2010 12:47:35 -0500 Received: from [199.232.76.173] (port=51754 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUOMU-0002TO-2N for qemu-devel@nongnu.org; Mon, 11 Jan 2010 12:47:30 -0500 Received: from verein.lst.de ([213.95.11.210]:42663) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1NUOMS-0007xn-6t for qemu-devel@nongnu.org; Mon, 11 Jan 2010 12:47:29 -0500 Date: Mon, 11 Jan 2010 18:47:23 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH] dmg: fix ->open failure Message-ID: <20100111174723.GA7204@lst.de> References: <20100111130654.GA24241@lst.de> <4B4B2B1F.1090203@redhat.com> <20100111134610.GA27135@lst.de> <4B4B2E00.90002@redhat.com> <20100111140000.GA28467@lst.de> <4B4B31A8.6010405@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4B31A8.6010405@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Christoph Hellwig , qemu-devel@nongnu.org On Mon, Jan 11, 2010 at 03:11:52PM +0100, Kevin Wolf wrote: > More or less the same hack, just in cleaner? Or trying to fundamentally > change things? I think you haven't answered yet to what I said in the > thread of my original hack. I'm quoting it here for convenience: Well, not dealing with the format list in raw, but rather in block.c > > Ok, if you start talking about layering, we can have a fundamental > > discussion on this topic and why the layering is broken anyway. > > Logically, we have image formats like qcow2, VMDK and raw, and they are > > stored in files, on CD-ROMs or general block devices. From a layering > > perspective, it is wrong to include the latter in the raw format driver > > in the first place. > > Actually, I think the differentiation between raw files and host_* is at > the same level as protocols are. Probably they should be implemented > very similarly. > > Do you think it's possible/worth the effort to try putting things > straight here? So what you want is basically: - hdev_* and file as protocols in addition to nbd/ftp/http/.. - a raw image format that can be used ontop of any protocol instead of an image format That would indeed be a much better, not to say actually logical layering. The raw image format would be more or less a no-op just stacking ontop of the protocol. If we can find a way to implement this efficiently it might be the way to go.