Skip to content
  • 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: default avatarTom Zanussi <zanussi@us.ibm.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    e82894f8