1. 23 9月, 2006 4 次提交
  2. 09 6月, 2006 1 次提交
    • D
      NFS: Split fs/nfs/inode.c · f7b422b1
      David Howells 提交于
      As fs/nfs/inode.c is rather large, heterogenous and unwieldy, the attached
      patch splits it up into a number of files:
      
       (*) fs/nfs/inode.c
      
           Strictly inode specific functions.
      
       (*) fs/nfs/super.c
      
           Superblock management functions for NFS and NFS4, normal access, clones
           and referrals.  The NFS4 superblock functions _could_ move out into a
           separate conditionally compiled file, but it's probably not worth it as
           there're so many common bits.
      
       (*) fs/nfs/namespace.c
      
           Some namespace-specific functions have been moved here.
      
       (*) fs/nfs/nfs4namespace.c
      
           NFS4-specific namespace functions (this could be merged into the previous
           file).  This file is conditionally compiled.
      
       (*) fs/nfs/internal.h
      
           Inter-file declarations, plus a few simple utility functions moved from
           fs/nfs/inode.c.
      
           Additionally, all the in-.c-file externs have been moved here, and those
           files they were moved from now includes this file.
      
      For the most part, the functions have not been changed, only some multiplexor
      functions have changed significantly.
      
      I've also:
      
       (*) Added some extra banner comments above some functions.
      
       (*) Rearranged the function order within the files to be more logical and
           better grouped (IMO), though someone may prefer a different order.
      
       (*) Reduced the number of #ifdefs in .c files.
      
       (*) Added missing __init and __exit directives.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      f7b422b1
  3. 21 3月, 2006 3 次提交
    • T
      NFS: Cleanup of NFS read code · ec06c096
      Trond Myklebust 提交于
      Same callback hierarchy inversion as for the NFS write calls. This patch is
      not strictly speaking needed by the O_DIRECT code, but avoids confusing
      differences between the asynchronous read and write code.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ec06c096
    • T
      NFS: Cleanup of NFS write code in preparation for asynchronous o_direct · 788e7a89
      Trond Myklebust 提交于
      This patch inverts the callback hierarchy for NFS write calls.
      
      Instead of having the NFSv2/v3/v4-specific code set up the RPC callback
      ops, we allow the original caller to do so. This allows for more
      flexibility w.r.t. how to set up and tear down the nfs_write_data
      structure while still allowing the NFSv3/v4 code to perform error
      handling.
      
      The greater flexibility is needed by the asynchronous O_DIRECT code, which
      wants to be able to hold on to the original nfs_write_data structures after
      the WRITE RPC call has completed in order to be able to replay them if the
      COMMIT call determines that the server has rebooted.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      788e7a89
    • C
      SUNRPC: eliminate rpc_call() · dead28da
      Chuck Lever 提交于
      Clean-up: replace rpc_call() helper with direct call to rpc_call_sync.
      
      This makes NFSv2 and NFSv3 synchronous calls more computationally
      efficient, and reduces stack consumption in functions that used to
      invoke rpc_call more than once.
      
      Test plan:
      Compile kernel with CONFIG_NFS enabled.  Connectathon on NFS version 2,
      version 3, and version 4 mount points.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      dead28da
  4. 07 1月, 2006 2 次提交
  5. 04 12月, 2005 1 次提交
  6. 28 10月, 2005 2 次提交
  7. 19 10月, 2005 1 次提交
  8. 17 8月, 2005 1 次提交
  9. 23 6月, 2005 1 次提交
  10. 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