qemu io介绍（一）

Qemu IO模型简述：

BlockBackend  --->  BlockDriverState  -----> qcow2     ----> raw
blk_co_pwritev ----> bdrv_co_pwritev ----> qcow2_co_pwritev
后端                                驱动层                              实现层（还有raw等格式）

qemu整个block后端模拟的是一个磁盘驱动器。磁盘驱动器的作用是获取或写入操作系统驱动给过来的偏移和数据，它包括针头和磁盘和读写电路。 
那为什么又要分为后端和驱动层呢？

BlockBackend  模式是块设备后端。块设备也包含很多种类，比如光驱、磁盘。它包含着设备的信息，比如块设备的型号“drive-virtio-disk0”、监视器； 而其他的驱动读写的操作则放在BlockDriverState 里面。
其实这两个也不是一定要分离，qemu 2.1.2就是不分离的，目前blk的接口很多都是包了一层bdrv接口而已。但是如果不分离的话，那么BlockDriverState 是一个大而全的东西。因为驱动是一个树状结构，所以看起来有点怪，每一级驱动里面都包含了一些不必要的东西，比如设备型号、监视器、IO限速、插拔通知等东西。
作者解释：

block: New BlockBackend

A block device consists of a frontend device model and a backend. A block backend has a tree of block drivers doing the actual work. The tree is managed by the block layer. We currently use a single abstraction BlockDriverState both for tree nodes and the backend as a whole. Drawbacks: * Its API includes both stuff that makes sense only at the block backend level (root of the tree) and stuff that's only for use within the block layer. This makes the API bigger and more complex than necessary. Moreover, it's not obvious which interfaces are meant for device models, and which really aren't. * Since device models keep a reference to their backend, the backend object can't just be destroyed. But for media change, we need to replace the tree. Our solution is to make the BlockDriverState generic, with actual driver state in a separate object, pointed to by member opaque. That lets us replace the tree by deinitializing and reinitializing its root. This special need of the root makes the data structure awkward everywhere in the tree. The general plan is to separate the APIs into "block backend", for use by device models, monitor and whatever other code dealing with block backends, and "block driver", for use by the block layer and whatever other code (if any) dealing with trees and tree nodes. Code dealing with block backends, device models in particular, should become completely oblivious of BlockDriverState. This should let us clean up both APIs, and the tree data structures. This commit is a first step. It creates a minimal "block backend" API: type BlockBackend and functions to create, destroy and find them. BlockBackend objects are created and destroyed exactly when root BlockDriverState objects are created and destroyed. "Root" in the sense of "in bdrv_states". They're not yet used for anything; that'll come shortly. A root BlockDriverState is created with bdrv_new_root(), so where to create a BlockBackend is obvious. Where these roots get destroyed isn't always as obvious. It is obvious in qemu-img.c, qemu-io.c and qemu-nbd.c, and in error paths of blockdev_init(), blk_connect(). That leaves destruction of objects successfully created by blockdev_init() and blk_connect(). blockdev_init() is used only by drive_new() and qmp_blockdev_add(). Objects created by the latter are currently indestructible (see commit 48f364d "blockdev: Refuse to drive_del something added with blockdev-add" and commit 2d246f0 "blockdev: Introduce DriveInfo.enable_auto_del"). Objects created by the former get destroyed by drive_del(). Objects created by blk_connect() get destroyed by blk_disconnect(). BlockBackend is reference-counted. Its reference count never exceeds one so far, but that's going to change. In drive_del(), the BB's reference count is surely one now. The BDS's reference count is greater than one when something else is holding a reference, such as a block job. In this case, the BB is destroyed right away, but the BDS lives on until all extra references get dropped.