From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39609 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OQjYp-0000tu-5K for qemu-devel@nongnu.org; Mon, 21 Jun 2010 12:09:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OQjYn-0005zV-LI for qemu-devel@nongnu.org; Mon, 21 Jun 2010 12:09:22 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:34544) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQjYn-0005zO-G9 for qemu-devel@nongnu.org; Mon, 21 Jun 2010 12:09:21 -0400 Received: by iwn10 with SMTP id 10so1194361iwn.4 for ; Mon, 21 Jun 2010 09:09:20 -0700 (PDT) Message-ID: <4C1F8EAD.3010804@codemonkey.ws> Date: Mon, 21 Jun 2010 11:09:17 -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> <4C1F8741.4030204@codemonkey.ws> <20100621160147.GA16112@lst.de> In-Reply-To: <20100621160147.GA16112@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 , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Gerd Hoffmann , Avi Kivity On 06/21/2010 11:01 AM, Christoph Hellwig wrote: > On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote: > >> There's just a couple cases we should consider: >> >> [1] -blockdev format=raw,file=/dev/cdrom,id=blk1 >> > >> For [1], we just defaulting transport to file is would not give us the >> same semantics we have today. Is that desirable? >> > By mentioning the host devices you're opening another can of worms here. > The host devices are another special case which is a rather problematic. > I think the best we can do is to eliminate the different protocols for > the host devices and fold them into file. For one the basic host > device Blockdriver really doesn't make any sense to be different from > file. The only differences are: > > - host_device sets the no_zero_init flag. This is something we could easily > do per-instance with an S_ISCHR || S_ISBLK check in the right place > - host_device has a different ->create method. Instead of truncating > the file to the image size it does an llseek to figure if the new > size fits. Again, this could be one method with an S_ISCHR || S_ISBLK > block check. (and btw, the llseek seems to be wrong for some weirded > unix variants, compare to raw_getlength). > - host_device implements the ioctl and aio_ioctl methods. We'll need > them for file anyway once my discard support lands. > > Now what's more interesting than the plain host_device are the magic > cdrom and floppy devices. These offer bdrv_is_inserted / > bdrv_media_changed / bdrv_eject eject methods, and once it a while do > some magic in bdrv_open. We could easily key those off with a small > host_device_operations structure inside raw-posix.c (which should be > rename file-posix.c these days). That would make the whole model a > lot more consistent, and we could get rid of all the device probing > special casing in the block layer which, which is a complete mess > due to the Windows vs Unix differences. > I fully agree here. The result would be a much cleaner distinction between format and transport once you get rid of the host device stuff. >> [2] -blockdev format=vvfat,file=/path/to/directory,id=blk1 >> >> >> It's not clear to me why [2] should be transport=vvfat. vvfat really >> isn't a transport. >> > Well, it's a wart if you want to be exact. But in the above model > it's a clearly a transport. It does not take an arbitrary BlockDriver > on the layer below it but implements it's own I/O methods not using the > qemu block layer - it maps from an image file the filesystem namespace. > Similar to file connects to a file on the local system and nbd/http > connects an image on a remote system. > > >> What about things like blkdebug and if we had >> something like a ramdisk? >> > A ramdisk again is a transport into a file that's purely in-memory. > You can trivially run any format we have ontop of it. > > blkdebug in it's current form is a trivial image format, just like raw > in the above terminology. It takes an arbitrary qemu BlockDriver as > input and then stacks on top. > > Think of a protocol/transport as the thing that implements the lowest > layer of the qemu block I/O stack which then maps to native I/O methods. > Yes, we're back to the whole discussion of leaf vs. non-leaf nodes. The fundamental question is, why make this distinction visible to the user? Why does the user care if something is a leaf vs. a non-leaf node? Regards, Anthony Liguori