From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUd1o-0006Rh-Hx for qemu-devel@nongnu.org; Tue, 12 Jan 2010 04:27:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUd1j-0006PD-9D for qemu-devel@nongnu.org; Tue, 12 Jan 2010 04:27:07 -0500 Received: from [199.232.76.173] (port=44997 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUd1i-0006P1-Kp for qemu-devel@nongnu.org; Tue, 12 Jan 2010 04:27:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9528) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUd1h-0000Jj-TM for qemu-devel@nongnu.org; Tue, 12 Jan 2010 04:27:02 -0500 Message-ID: <4B4C4024.40103@redhat.com> Date: Tue, 12 Jan 2010 10:25:56 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] dmg: fix ->open failure 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> <20100111174723.GA7204@lst.de> In-Reply-To: <20100111174723.GA7204@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Am 11.01.2010 18:47, schrieb Christoph Hellwig: > On Mon, Jan 11, 2010 at 03:11:52PM +0100, Kevin Wolf wrote: >>> 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 Yes, this is pretty much what I was thinking of. > 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. Right, getting it done for raw without losing performance was more or less my only concern. I mean, remapping directly to the protocol in bdrv_open is exactly what we want to avoid. The question is if stubs to pass requests down to the protocol are really that expensive. It shouldn't be much more than two additional function calls. Kevin