diff options
author | Rusty Russell <rusty@rustcorp.com.au> | 2012-01-12 15:44:42 +1030 |
---|---|---|
committer | Rusty Russell <rusty@rustcorp.com.au> | 2012-01-12 15:44:42 +1030 |
commit | 5dfc17628d57f9e62043ed0cba03a6e3eb019a78 (patch) | |
tree | a488dd3ea081166342904224db3cf039758f23d4 /include/linux/virtio.h | |
parent | 1e214a5c1a7e901fc8e98ad6ef84f11005f9ee9d (diff) | |
download | blackbird-op-linux-5dfc17628d57f9e62043ed0cba03a6e3eb019a78.tar.gz blackbird-op-linux-5dfc17628d57f9e62043ed0cba03a6e3eb019a78.zip |
virtio: document functions better.
The old documentation is left over from when we used a structure with
strategy pointers.
And move the documentation to the C file as per kernel practice.
Though I disagree...
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'include/linux/virtio.h')
-rw-r--r-- | include/linux/virtio.h | 47 |
1 files changed, 0 insertions, 47 deletions
diff --git a/include/linux/virtio.h b/include/linux/virtio.h index 4c069d8bd740..73ad7243128f 100644 --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -25,53 +25,6 @@ struct virtqueue { void *priv; }; -/** - * operations for virtqueue - * virtqueue_add_buf: expose buffer to other end - * vq: the struct virtqueue we're talking about. - * sg: the description of the buffer(s). - * out_num: the number of sg readable by other side - * in_num: the number of sg which are writable (after readable ones) - * data: the token identifying the buffer. - * gfp: how to do memory allocations (if necessary). - * Returns remaining capacity of queue (sg segments) or a negative error. - * virtqueue_kick: update after add_buf - * vq: the struct virtqueue - * After one or more add_buf calls, invoke this to kick the other side. - * virtqueue_get_buf: get the next used buffer - * vq: the struct virtqueue we're talking about. - * len: the length written into the buffer - * Returns NULL or the "data" token handed to add_buf. - * virtqueue_disable_cb: disable callbacks - * vq: the struct virtqueue we're talking about. - * Note that this is not necessarily synchronous, hence unreliable and only - * useful as an optimization. - * virtqueue_enable_cb: restart callbacks after disable_cb. - * vq: the struct virtqueue we're talking about. - * This re-enables callbacks; it returns "false" if there are pending - * buffers in the queue, to detect a possible race between the driver - * checking for more work, and enabling callbacks. - * virtqueue_enable_cb_delayed: restart callbacks after disable_cb. - * vq: the struct virtqueue we're talking about. - * This re-enables callbacks but hints to the other side to delay - * interrupts until most of the available buffers have been processed; - * it returns "false" if there are many pending buffers in the queue, - * to detect a possible race between the driver checking for more work, - * and enabling callbacks. - * virtqueue_detach_unused_buf: detach first unused buffer - * vq: the struct virtqueue we're talking about. - * Returns NULL or the "data" token handed to add_buf - * virtqueue_get_vring_size: return the size of the virtqueue's vring - * vq: the struct virtqueue containing the vring of interest. - * Returns the size of the vring. - * - * Locking rules are straightforward: the driver is responsible for - * locking. No two operations may be invoked simultaneously, with the exception - * of virtqueue_disable_cb. - * - * All operations can be called in any context. - */ - int virtqueue_add_buf_gfp(struct virtqueue *vq, struct scatterlist sg[], unsigned int out_num, |