1. 09 Jan, 2006 2 commits
    • Tom Zanussi's avatar
      [PATCH] relayfs: export relayfs_create_file() with fileops param · 907f2c77
      Tom Zanussi authored
      This patch adds a mandatory fileops param to relayfs_create_file() and exports
      that function so that clients can use it to create files defined by their own
      set of file operations, in relayfs.  The purpose is to allow relayfs
      applications to create their own set of 'control' files alongside their relay
      files in relayfs rather than having to create them in /proc or debugfs for
      instance.  relayfs_create_file() is also used by relay_open_buf() to create
      the relay files for a channel.  In this case, a pointer to
      relayfs_file_operations is passed in, along with a pointer to the buffer
      associated with the file.
      Signed-off-by: 's avatarTom Zanussi <zanussi@us.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      907f2c77
    • Tom Zanussi's avatar
      [PATCH] relayfs: decouple buffer creation from inode creation · 6625b861
      Tom Zanussi authored
      The patch series implementa or fixes 3 things that were specifically requested
      or suggested by relayfs users:
      
      - support for non-relay files (patches 1-6)
      
      Currently, the relayfs API only supports the creation of directories
      (relayfs_create_dir()) and relay files (relay_open()).  These patches adds
      support for non-relay files (relayfs_create_file()).  This is so relayfs
      applications can create 'control files' in relayfs itself rather than in /proc
      or via a netlink channel, as is currently done in the relay-app examples.
      Basically what this amounts to is exporting relayfs_create_file() with an
      additional file_ops param that clients can use to supply file operations for
      their own special-purpose files in relayfs.
      
      - make exported relay file ops useful (patches 7-8)
      
      The relayfs relay_file_operations have always been exported, the intent being
      to make it possible to create relay files in other filesystems such as
      debugfs.  The problem, though, is that currently the file operations are too
      tightly coupled to relayfs to actually be used for this purpose.  This patch
      fixes that by adding a couple of callback functions that allow a client to
      hook into relay_open()/close() and supply the files that will be used to
      represent the channel buffers; the default implementation if no callbacks are
      defined is to create the files in relayfs.
      
      - add an option to create global relay buffer (patches 9-10) The file creation
      callback also supplies an optional param, is_global, that can be used by
      clients to create a single global relayfs buffer instead of the default
      per-cpu buffers.  This was suggested as being useful for certain debugging
      applications where it's more convenient to be able to get all the data from a
      single channel without having to go to the bother of dealing with per-cpu
      files.
      
      - cleanup, some renaming and Documentation updates (patches 11-12)
      
      There were several comments that the use of netlink in the example code was
      non-intuitive and in fact the whole relay-app business was needlessly
      confusing.  Based on that feedback, the example code has been completely
      converted over to relayfs control files as supported by this patch, and have
      also been made completely self-contained.
      
      The converted examples along with a couple of new examples that demonstrate
      using exported relay files can be found in relay-apps tarball:
      http://prdownloads.sourceforge.net/relayfs/relay-apps-0.9.tar.gz?download
      
      This patch:
      
      Separate buffer create/destroy from inode create/destroy.  We want to be able
      to associate other data and not just relay buffers with inodes.  Buffer
      create/destroy is moved out of inode.c and into relayfs core code.
      Signed-off-by: 's avatarTom Zanussi <zanussi@us.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      6625b861
  2. 07 Sep, 2005 1 commit
    • Tom Zanussi's avatar
      [PATCH] relayfs · e82894f8
      Tom Zanussi authored
      Here's the latest version of relayfs, against linux-2.6.11-mm2.  I'm hoping
      you'll consider putting this version back into your tree - the previous
      rounds of comment seem to have shaken out all the API issues and the number
      of comments on the code itself have also steadily dwindled.
      
      This patch is essentially the same as the relayfs redux part 5 patch, with
      some minor changes based on reviewer comments.  Thanks again to Pekka
      Enberg for those.  The patch size without documentation is now a little
      smaller at just over 40k.  Here's a detailed list of the changes:
      
      - removed the attribute_flags in relay open and changed it to a
        boolean specifying either overwrite or no-overwrite mode, and removed
        everything referencing the attribute flags.
      - added a check for NULL names in relayfs_create_entry()
      - got rid of the unnecessary multiple labels in relay_create_buf()
      - some minor simplification of relay_alloc_buf() which got rid of a
        couple params
      - updated the Documentation
      
      In addition, this version (through code contained in the relay-apps tarball
      linked to below, not as part of the relayfs patch) tries to make it as easy
      as possible to create the cooperating kernel/user pieces of a typical and
      common type of logging application, one where kernel logging is kicked off
      when a user space data collection app starts and stops when the collection
      app exits, with the data being automatically logged to disk in between.  To
      create this type of application, you basically just include a header file
      (relay-app.h, included in the relay-apps tarball) in your kernel module,
      define a couple of callbacks and call an initialization function, and on
      the user side call a single function that sets up and continuously monitors
      the buffers, and writes data to files as it becomes available.  Channels
      are created when the collection app is started and destroyed when it exits,
      not when the kernel module is inserted, so different channel buffer sizes
      can be specified for each separate run via command-line options.  See the
      README in the relay-apps tarball for details.
      
      Also included in the relay-apps tarball are a couple examples
      demonstrating how you can use this to create quick and dirty kernel
      logging/debugging applications.  They are:
      
      - tprintk, short for 'tee printk', which temporarily puts a kprobe on
        printk() and writes a duplicate stream of printk output to a relayfs
        channel.  This could be used anywhere there's printk() debugging code
        in the kernel which you'd like to exercise, but would rather not have
        your system logs cluttered with debugging junk.  You'd probably want
        to kill klogd while you do this, otherwise there wouldn't be much
        point (since putting a kprobe on printk() doesn't change the output
        of printk()).  I've used this method to temporarily divert the packet
        logging output of the iptables LOG target from the system logs to
        relayfs files instead, for instance.
      
      - klog, which just provides a printk-like formatted logging function
        on top of relayfs.  Again, you can use this to keep stuff out of your
        system logs if used in place of printk.
      
      The example applications can be found here:
      
      http://prdownloads.sourceforge.net/dprobes/relay-apps.tar.gz?download
      
      From: Christoph Hellwig <hch@lst.de>
      
        avoid lookup_hash usage in relayfs
      Signed-off-by: 's avatarTom Zanussi <zanussi@us.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      e82894f8