From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37824 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OQj4F-0001lt-Ni for qemu-devel@nongnu.org; Mon, 21 Jun 2010 11:37:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OQj4E-0001B3-HK for qemu-devel@nongnu.org; Mon, 21 Jun 2010 11:37:47 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:35021) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQj4E-0001As-Cg for qemu-devel@nongnu.org; Mon, 21 Jun 2010 11:37:46 -0400 Received: by iwn10 with SMTP id 10so1166410iwn.4 for ; Mon, 21 Jun 2010 08:37:45 -0700 (PDT) Message-ID: <4C1F8741.4030204@codemonkey.ws> Date: Mon, 21 Jun 2010 10:37:37 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack References: <4C1DF2C1.5040505@redhat.com> <4C1F2093.3060807@redhat.com> <4C1F6482.7020406@codemonkey.ws> <4C1F6973.5020003@redhat.com> <4C1F6B36.8070508@codemonkey.ws> <4C1F70AF.8030108@redhat.com> <4C1F7C6B.3040602@codemonkey.ws> <20100621150058.GA14072@lst.de> In-Reply-To: <20100621150058.GA14072@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Kevin Wolf , Christoph Hellwig , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Gerd Hoffmann , Avi Kivity On 06/21/2010 10:00 AM, Christoph Hellwig wrote: > Keeping these separate makes a lot of sense to me, even with my user > hat on. And as lon as we don't require the transport protocol but fall > back to file it's even more understandable for the users, as he simply > doesn't have to care about it for the 99% case. Now for the image > format specifying it usually is a good thing as the autodetecting could > easily get into trouble when the guest creates say a full-device qcow2 > image in a device that's an image file on the host. > I agree that transport makes a lot more sense. There's just a couple cases we should consider: [1] -blockdev format=raw,file=/dev/cdrom,id=blk1 [2] -blockdev format=vvfat,file=/path/to/directory,id=blk1 For [1], we just defaulting transport to file is would not give us the same semantics we have today. Is that desirable? It's not clear to me why [2] should be transport=vvfat. vvfat really isn't a transport. What about things like blkdebug and if we had something like a ramdisk? Regards, Anthony Liguori