下面引用Tapdisk2 的README文檔，對Tapdisk2的新磁盤類型開發做簡要說明

Tapdisk Development

People regularly ask how to develop their own tapdisk drivers, and
while it has not yet been well documented, the process is relatively
easy. Here I will provide a brief overview. The best reference, of
course, comes from the existing drivers. Specifically,
blktap2/drivers/block-ram.c and blktap2/drivers/block-aio.c provide
the clearest examples of simple drivers.

Setup:

First you need to register your new driver with blktap. This is done
in disktypes.h. There are five things that you must do. To
demonstrate, I will create a disk called "mynewdisk", you can name
yours freely.

1) Forward declare an instance of struct tap_disk.

e.g. -
extern struct tap_disk tapdisk_mynewdisk;

2) Claim one of the unused disk type numbers, take care to observe the
MAX_DISK_TYPES macro, increasing the number if necessary.

e.g. -
#define DISK_TYPE_MYNEWDISK 10

3) Create an instance of disk_info_t. The bulk of this file contains examples of these.

e.g. -

 static disk_info_t mynewdisk_disk = {
           DISK_TYPE_MYNEWDISK,
           "My New Disk (mynewdisk)",
           "mynewdisk",
           0,
   #ifdef TAPDISK
           &tapdisk_mynewdisk,
   #endif
   };

A few words about what these mean. The first field must be the disk
type number you claimed in step (2). The second field is a string
describing your disk, and may contain any relevant info. The third
field is the name of your disk as will be used by the tapdisk2 utility
and xend (for example tapdisk2 -n mynewdisk:/path/to/disk.image, or in
your xm create config file). The forth is binary and determines
whether you will have one instance of your driver, or many. Here, a 1
means that your driver is a singleton and will coordinate access to
any number of tap devices. 0 is more common, meaning that you will
have one driver for each device that is created. The final field
should contain a reference to the struct tap_disk you created in step
(1).

4) Add a reference to your disk info structure (from step (3)) to the
dtypes array. Take care here - you need to place it in the position
corresponding to the device type number you claimed in step (2). So
we would place &mynewdisk_disk in dtypes[10]. Look at the other
devices in this array and pad with "&null_disk," as necessary.

5) Modify the xend python scripts. You need to add your disk name to
the list of disks that xend recognizes.

edit:
tools/python/xen/xend/server/BlktapController.py

And add your disk to the "blktap_disk_types" array near the top of
your file. Use the same name you specified in the third field of step
(3). The order of this list is not important.

Now your driver is ready to be written. Create a block-mynewdisk.c in
tools/blktap2/drivers and add it to the Makefile.

Development:

Copying block-aio.c and block-ram.c would be a good place to start.
Read those files as you go through this, I will be assisting by
commenting on a few useful functions and structures.

struct tap_disk:

Remember the forward declaration in step (1) of the setup phase above?
Now is the time to make that structure a reality. This structure
contains a list of function pointers for all the routines that will be
asked of your driver. Currently the required functions are open,
close, read, write, get_parent_id, validate_parent, and debug.

e.g. -

   struct tap_disk tapdisk_mynewdisk = {
           .disk_type          = "tapdisk_mynewdisk",
           .flags              = 0,
           .private_data_size  = sizeof(struct tdmynewdisk_state),
           .td_open            = tdmynewdisk_open,
                  ....

The private_data_size field is used to provide a structure to store
the state of your device. It is very likely that you will want
something here, but you are free to design whatever structure you
want. Blktap will allocate this space for you, you just need to tell
it how much space you want.

tdmynewdisk_open:

This is the open routine. The first argument is a structure
representing your driver. Two fields in this array are
interesting.

driver->data will contain a block of memory of the size your requested
in in the .private_data_size field of your struct tap_disk (above).

driver->info contains a structure that details information about your
disk. You need to fill this out. By convention this is done with a
_get_image_info() function. Assign a size (the total number of
sectors), sector_size (the size of each sector in bytes, and set
driver->info->info to 0.

The second parameter contains the name that was specified in the
creation of your device, either through xend, or on the command line
with tapdisk2. Usually this specifies a file that you will open in
this routine. The final parameter, flags, contains one of a number of
flags specified in tapdisk.h that may change the way you treat the
disk.

_queue_read/write:

These are your read and write operations. What you do here will
depend on your disk, but you should do exactly one of-

1) call td_complete_request with either error or success code.

2) Call td_forward_request, which will forward the request to the next
driver in the stack.

3) Queue the request for asynchronous processing with
td_prep_read/write. In doing so, you will also register a callback
for request completion. When the request completes you must do one of
options (1) or (2) above. Finally, call td_queue_tiocb to submit the
request to a wait queue.

The above functions are defined in tapdisk-interface.c. If you don't
use them as specified you will run into problems as your driver will
fail to inform blktap of the state of requests that have been
submitted. Blktap keeps track of all requests and does not like losing track.

_close, _get_parent_id, _validate_parent:

These last few tend to be very routine. _close is called when the
device is closed, and also when it is paused (in this case, open will
also be called later). The other functions are used in stacking
drivers. Most often drivers will return TD_NO_PARENT and -EINVAL,
respectively.