|
From: | Max Reitz |
Subject: | Re: [Qemu-devel] writing a QEMU block driver |
Date: | Mon, 20 Oct 2014 09:50:35 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 |
Am 2014-10-17 um 16:59 schrieb Sandeep
Joshi:
I'm not sure, but the main difference should be that bdrv_file_open() is invoked for protocol block drivers, whereas bdrv_open() is invoked for format block drivers. A couple of months ago, there was still a top-level bdrv_file_open() function which has since been integrated into bdrv_open(), so we might probably want to remove bdrv_file_open() in the future as well... But for now, use bdrv_file_open() for protocol drivers and bdrv_open() for format drivers.
Setting format_name does not make a block driver a format driver. A block driver can only be either protocol or format driver, and the distinction is probably made (again, I'd have to look it up to be sure) by protocol drivers setting protocol_name and bdrv_file_open(), whereas format drivers do not. So you just need to set protocol_name and bdrv_file_open() (and format_name as well, see nbd for an example where protocol_name and format_name differ) and qemu knows your block driver is a protocol driver and any format drivers will work on top of it. You should not set bdrv_open(), however. Once again, I'm not 100 % sure, but it should work that way. Just by the way, I can very well imagine that the distinction between protocol and format block drivers will disappear (at least in the code) in the future. But that should not be any of your concern. :-)
Well, you can always use gdb with break points and backtraces. At least that's what I'd do. For your first question: Yes, for each guest device or let's say virtual guest device (because creating an image is not done through a guest device, but the only thing missing from a guest device configuration is in fact the device itself), there is a tree of BlockDriverStates. Every request runs through the whole tree. It may not touch all nodes, but it will start from the top (which is normally a format BDS) and then proceed as far as the block drivers create new requests to their children. Or, to be more technical: A request only goes to the topmost node in the BDS tree (the root). If need be, it will manually forward it to its child (which normally is bs->file if bs is a pointer to the BlockDriverState) or children (e.g. bs->backing_hd, the backing file, or driver-specific things, such as the children for the quorum block driver which are not stored in the BlockDriverState). This doesn't apply so well to bdrv_create(), because that function does not work on BlockDriverStates, but I'm hoping you're seeing the point. Shameless self plug: Regarding this whole BDS tree thing I can recommend Kevin's and my presentation from this year's KVM Forum: http://events.linuxfoundation.org/sites/events/files/slides/blockdev.pdf Max |
[Prev in Thread] | Current Thread | [Next in Thread] |