[patch 13/14] sunrpc: Move struct cache_request to linux/sunrpc/cache.h

[Greg Banks <gnb@sgi.com>]

Now the definition of struct cache_request is in the same header file
that declares struct cache_detail, instead of being in a .c file.

Signed-off-by: Greg Banks <gnb@sgi.com>
---

 include/linux/sunrpc/cache.h |   35 ++++++++++++++++++++++++++++++++
 net/sunrpc/cache.c           |   35 --------------------------------
 2 files changed, 35 insertions(+), 35 deletions(-)

Index: bfields/include/linux/sunrpc/cache.h
===================================================================
--- bfields.orig/include/linux/sunrpc/cache.h
+++ bfields/include/linux/sunrpc/cache.h
@@ -131,6 +131,41 @@ struct cache_deferred_req {
 					   int too_many);
 };
 
+/*
+ * Caches communicate with user-space.
+ *
+ * We have a magic /proc file - /proc/sunrpc/<cachename>/channel.
+ *
+ * On read, you get a full request.  If the length passed
+ * to read() is too short, you get nothing and the message is dropped,
+ * which is bad.  So you should use a sufficently large length,
+ * for example PAGE_SIZE.  If there are no requests queued,
+ * read() returns 0.
+ *
+ * On write, an update is processed.  This may, as a side effect,
+ * cause a previously queued request to be de-queued and removed.
+ * Userspace can also pre-emptively write updates which the kernel
+ * has not yet requested.
+ *
+ * Poll works if anything to read, and always allows write.
+ *
+ * The channel is implemented by two linked lists of cache_request
+ * objects.  cd->to_read is requests which have been generated in
+ * the kernel and are waiting for a userspace process to read them.
+ * cd->to_write is requests which have been read by userspace and
+ * are awaiting a reply to be written.
+ *
+ * Both lists are protected by cd->queue_lock.
+ */
+
+struct cache_request {
+	struct list_head	list;
+	atomic_t		count;
+	struct cache_head	*item;
+	int			len;
+	char			buf[0];
+};
+
 
 extern struct cache_head *
 sunrpc_cache_lookup(struct cache_detail *detail,
Index: bfields/net/sunrpc/cache.c
===================================================================
--- bfields.orig/net/sunrpc/cache.c
+++ bfields/net/sunrpc/cache.c
@@ -659,41 +659,6 @@ void cache_clean_deferred(void *owner)
 	}
 }
 
-/*
- * Caches communicate with user-space.
- *
- * We have a magic /proc file - /proc/sunrpc/<cachename>/channel.
- *
- * On read, you get a full request.  If the length passed
- * to read() is too short, you get nothing and the message is dropped,
- * which is bad.  So you should use a sufficently large length,
- * for example PAGE_SIZE.  If there are no requests queued,
- * read() returns 0.
- *
- * On write, an update is processed.  This may, as a side effect,
- * cause a previously queued request to be de-queued and removed.
- * Userspace can also pre-emptively write updates which the kernel
- * has not yet requested.
- *
- * Poll works if anything to read, and always allows write.
- *
- * The channel is implemented by two linked lists of cache_request
- * objects.  cd->to_read is requests which have been generated in
- * the kernel and are waiting for a userspace process to read them.
- * cd->to_write is requests which have been read by userspace and
- * are awaiting a reply to be written.
- *
- * Both lists are protected by cd->queue_lock.
- */
-
-struct cache_request {
-	struct list_head	list;
-	atomic_t		count;
-	struct cache_head	*item;
-	int			len;
-	char			buf[0];
-};
-
 static void
 cache_request_put(struct cache_request *rq, struct cache_detail *cd)
 {

--
-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.