summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>2011-05-05 18:41:03 +0200
committerKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>2011-05-12 14:55:56 +0200
commit6dcfb751c927879399e404b3885cbdef7d8d368b (patch)
treea8c23cddfb6af14684e472725137f7c70f065c74 /include
parentxen-blkfront: fix data size for xenbus_gather in blkfront_connect (diff)
downloadlinux-6dcfb751c927879399e404b3885cbdef7d8d368b.tar.xz
linux-6dcfb751c927879399e404b3885cbdef7d8d368b.zip
xen-blkfront: Provide for 'feature-flush-cache' the BLKIF_OP_WRITE_FLUSH_CACHE operation.
The operation BLKIF_OP_WRITE_FLUSH_CACHE has existed in the Xen tree header file for years but it was never present in the Linux tree because the frontend (nor the backend) supported this interface. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Diffstat (limited to 'include')
-rw-r--r--include/xen/interface/io/blkif.h13
1 files changed, 13 insertions, 0 deletions
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index 61e523af3c46..3d5d6db864fe 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -45,6 +45,19 @@ typedef uint64_t blkif_sector_t;
#define BLKIF_OP_WRITE_BARRIER 2
/*
+ * Recognised if "feature-flush-cache" is present in backend xenbus
+ * info. A flush will ask the underlying storage hardware to flush its
+ * non-volatile caches as appropriate. The "feature-flush-cache" node
+ * contains a boolean indicating whether flush requests are likely to
+ * succeed or fail. Either way, a flush request may fail at any time
+ * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
+ * block-device hardware. The boolean simply indicates whether or not it
+ * is worthwhile for the frontend to attempt flushes. If a backend does
+ * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
+ * "feature-flush-cache" node!
+ */
+#define BLKIF_OP_FLUSH_DISKCACHE 3
+/*
* Maximum scatter/gather segments per request.
* This is carefully chosen so that sizeof(struct blkif_ring) <= PAGE_SIZE.
* NB. This could be 12 if the ring indexes weren't stored in the same page.