1. 08 11月, 2005 1 次提交
  2. 10 9月, 2005 2 次提交
    • M
      [PATCH] FUSE - MAINTAINERS, Kconfig and Makefile changes · 04578f17
      Miklos Szeredi 提交于
      This patch adds FUSE filesystem to MAINTAINERS, fs/Kconfig and
      fs/Makefile.
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      04578f17
    • E
      [PATCH] v9fs: Documentation, Makefiles, Configuration · 93fa58cb
      Eric Van Hensbergen 提交于
      OVERVIEW
      
      V9FS is a distributed file system for Linux which provides an
      implementation of the Plan 9 resource sharing protocol 9P.  It can be
      used to share all sorts of resources: static files, synthetic file servers
      (such as /proc or /sys), devices, and application file servers (such as
      FUSE).
      
      BACKGROUND
      
      Plan 9 (http://plan9.bell-labs.com/plan9) is a research operating
      system and associated applications suite developed by the Computing
      Science Research Center of AT&T Bell Laboratories (now a part of
      Lucent Technologies), the same group that developed UNIX , C, and C++.
      Plan 9 was initially released in 1993 to universities, and then made
      generally available in 1995. Its core operating systems code laid the
      foundation for the Inferno Operating System released as a product by
      Lucent Bell-Labs in 1997. The Inferno venture was the only commercial
      embodiment of Plan 9 and is currently maintained as a product by Vita
      Nuova (http://www.vitanuova.com). After updated releases in 2000 and
      2002, Plan 9 was open-sourced under the OSI approved Lucent Public
      License in 2003.
      
      The Plan 9 project was started by Ken Thompson and Rob Pike in 1985.
      Their intent was to explore potential solutions to some of the
      shortcomings of UNIX in the face of the widespread use of high-speed
      networks to connect machines. In UNIX, networking was an afterthought
      and UNIX clusters became little more than a network of stand-alone
      systems. Plan 9 was designed from first principles as a seamless
      distributed system with integrated secure network resource sharing.
      Applications and services were architected in such a way as to allow
      for implicit distribution across a cluster of systems. Configuring an
      environment to use remote application components or services in place
      of their local equivalent could be achieved with a few simple command
      line instructions. For the most part, application implementations
      operated independent of the location of their actual resources.
      
      Commercial operating systems haven't changed much in the 20 years
      since Plan 9 was conceived. Network and distributed systems support is
      provided by a patchwork of middle-ware, with an endless number of
      packages supplying pieces of the puzzle. Matters are complicated by
      the use of different complicated protocols for individual services,
      and separate implementations for kernel and application resources.
      The V9FS project (http://v9fs.sourceforge.net) is an attempt to bring
      Plan 9's unified approach to resource sharing to Linux and other
      operating systems via support for the 9P2000 resource sharing
      protocol.
      
      V9FS HISTORY
      
      V9FS was originally developed by Ron Minnich and Maya Gokhale at Los
      Alamos National Labs (LANL) in 1997.  In November of 2001, Greg Watson
      setup a SourceForge project as a public repository for the code which
      supported the Linux 2.4 kernel.
      
      About a year ago, I picked up the initial attempt Ron Minnich had
      made to provide 2.6 support and got the code integrated into a 2.6.5
      kernel.   I then went through a line-for-line re-write attempting to
      clean-up the code while more closely following the Linux Kernel style
      guidelines.  I co-authored a paper with Ron Minnich on the V9FS Linux
      support including performance comparisons to NFSv3 using Bonnie and
      PostMark - this paper appeared at the USENIX/FREENIX 2005
      conference in April 2005:
      ( http://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html ).
      
      CALL FOR PARTICIPATION/REQUEST FOR COMMENTS
      
      Our 2.6 kernel support is stabilizing and we'd like to begin pursuing
      its integration into the official kernel tree.  We would appreciate any
      review, comments, critiques, and additions from this community and are
      actively seeking people to join our project and help us produce
      something that would be acceptable and useful to the Linux community.
      
      STATUS
      
      The code is reasonably stable, although there are no doubt corner cases
      our regression tests haven't discovered yet.  It is in regular use by several
      of the developers and has been tested on x86 and PowerPC
      (32-bit and 64-bit) in both small and large (LANL cluster) deployments.
      Our current regression tests include fsx, bonnie, and postmark.
      
      It was our intention to keep things as simple as possible for this
      release -- trying to focus on correctness within the core of the
      protocol support versus a rich set of features.  For example: a more
      complete security model and cache layer are in the road map, but
      excluded from this release.   Additionally, we have removed support for
      mmap operations at Al Viro's request.
      
      PERFORMANCE
      
      Detailed performance numbers and analysis are included in the FREENIX
      paper, but we show comparable performance to NFSv3 for large file
      operations based on the Bonnie benchmark, and superior performance for
      many small file operations based on the PostMark benchmark.   Somewhat
      preliminary graphs (from the FREENIX paper) are available
      (http://v9fs.sourceforge.net/perf/index.html).
      
      RESOURCES
      
      The source code is available in a few different forms:
      
      tarballs: http://v9fs.sf.net
      CVSweb: http://cvs.sourceforge.net/viewcvs.py/v9fs/linux-9p/
      CVS: :pserver:anonymous@cvs.sourceforge.net:/cvsroot/v9fs/linux-9p
      Git: rsync://v9fs.graverobber.org/v9fs (webgit: http://v9fs.graverobber.org)
      9P: tcp!v9fs.graverobber.org!6564
      
      The user-level server is available from either the Plan 9 distribution
      or from http://v9fs.sf.net
      Other support applications are still being developed, but preliminary
      version can be downloaded from sourceforge.
      
      Documentation on the protocol has historically been the Plan 9 Man
      pages (http://plan9.bell-labs.com/sys/man/5/INDEX.html), but there is
      an effort under way to write a more complete Internet-Draft style
      specification (http://v9fs.sf.net/rfc).
      
      There are a couple of mailing lists supporting v9fs, but the most used
      is v9fs-developer@lists.sourceforge.net -- please direct/cc your
      comments there so the other v9fs contibutors can participate in the
      conversation.  There is also an IRC channel: irc://freenode.net/#v9fs
      
      This part of the patch contains Documentation, Makefiles, and configuration
      file changes.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      93fa58cb
  3. 08 9月, 2005 1 次提交
    • T
      [PATCH] relayfs · e82894f8
      Tom Zanussi 提交于
      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: NTom Zanussi <zanussi@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e82894f8
  4. 13 7月, 2005 1 次提交
    • R
      [PATCH] inotify · 0eeca283
      Robert Love 提交于
      inotify is intended to correct the deficiencies of dnotify, particularly
      its inability to scale and its terrible user interface:
      
              * dnotify requires the opening of one fd per each directory
                that you intend to watch. This quickly results in too many
                open files and pins removable media, preventing unmount.
              * dnotify is directory-based. You only learn about changes to
                directories. Sure, a change to a file in a directory affects
                the directory, but you are then forced to keep a cache of
                stat structures.
              * dnotify's interface to user-space is awful.  Signals?
      
      inotify provides a more usable, simple, powerful solution to file change
      notification:
      
              * inotify's interface is a system call that returns a fd, not SIGIO.
      	  You get a single fd, which is select()-able.
              * inotify has an event that says "the filesystem that the item
                you were watching is on was unmounted."
              * inotify can watch directories or files.
      
      Inotify is currently used by Beagle (a desktop search infrastructure),
      Gamin (a FAM replacement), and other projects.
      
      See Documentation/filesystems/inotify.txt.
      Signed-off-by: NRobert Love <rml@novell.com>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0eeca283
  5. 28 6月, 2005 1 次提交
    • J
      [PATCH] Update cfq io scheduler to time sliced design · 22e2c507
      Jens Axboe 提交于
      This updates the CFQ io scheduler to the new time sliced design (cfq
      v3).  It provides full process fairness, while giving excellent
      aggregate system throughput even for many competing processes.  It
      supports io priorities, either inherited from the cpu nice value or set
      directly with the ioprio_get/set syscalls.  The latter closely mimic
      set/getpriority.
      
      This import is based on my latest from -mm.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22e2c507
  6. 23 6月, 2005 1 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4