From 3ee000a48268c183e4de866aff24652b828df751 Mon Sep 17 00:00:00 2001 From: Tom Zanussi Date: Sun, 8 Jan 2006 01:02:27 -0800 Subject: [PATCH] --- yaml --- r: 16939 b: refs/heads/master c: 925ac8a2b637466ba0ad8dfaf7b49aa9a362502f h: refs/heads/master i: 16937: 63156af70e04d812e013301111ca52a4356225b0 16935: ed5ee832781002ddfbfb4624b5ba884ef26685d5 v: v3 --- [refs] | 2 +- trunk/Documentation/filesystems/relayfs.txt | 23 +++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/[refs] b/[refs] index fbed2c7e2991..a9fd79943c4e 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: aaea25d7a68a7f72e167dc1698b66a15edc71883 +refs/heads/master: 925ac8a2b637466ba0ad8dfaf7b49aa9a362502f diff --git a/trunk/Documentation/filesystems/relayfs.txt b/trunk/Documentation/filesystems/relayfs.txt index d803abed29f0..0720a049d0b8 100644 --- a/trunk/Documentation/filesystems/relayfs.txt +++ b/trunk/Documentation/filesystems/relayfs.txt @@ -125,6 +125,8 @@ Here's a summary of the API relayfs provides to in-kernel clients: relay_reset(chan) relayfs_create_dir(name, parent) relayfs_remove_dir(dentry) + relayfs_create_file(name, parent, mode, fops, data) + relayfs_remove_file(dentry) channel management typically called on instigation of userspace: @@ -320,6 +322,27 @@ forces a sub-buffer switch on all the channel buffers, and can be used to finalize and process the last sub-buffers before the channel is closed. +Creating non-relay files +------------------------ + +relay_open() automatically creates files in the relayfs filesystem to +represent the per-cpu kernel buffers; it's often useful for +applications to be able to create their own files alongside the relay +files in the relayfs filesystem as well e.g. 'control' files much like +those created in /proc or debugfs for similar purposes, used to +communicate control information between the kernel and user sides of a +relayfs application. For this purpose the relayfs_create_file() and +relayfs_remove_file() API functions exist. For relayfs_create_file(), +the caller passes in a set of user-defined file operations to be used +for the file and an optional void * to a user-specified data item, +which will be accessible via inode->u.generic_ip (see the relay-apps +tarball for examples). The file_operations are a required parameter +to relayfs_create_file() and thus the semantics of these files are +completely defined by the caller. + +See the relay-apps tarball at http://relayfs.sourceforge.net for +examples of how these non-relay files are meant to be used. + Misc ----