1. 17 12月, 2010 3 次提交
  2. 23 11月, 2010 2 次提交
    • C
      hfsplus: optimize fsync · e3494705
      Christoph Hellwig 提交于
      Avoid doing unessecary work in fsync.  Do nothing unless the inode
      was marked dirty, and only write the various metadata inodes out if
      they contain any dirty state from this inode.  This is archived by
      adding three new dirty bits to the hfsplus-specific inode which are
      set in the correct places.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      e3494705
    • C
      hfsplus: split up inode flags · b33b7921
      Christoph Hellwig 提交于
      Split the flags field in the hfsplus inode into an extent_state
      flag that is locked by the extent_lock, and a new flags field
      that uses atomic bitops.  The second will grow more flags in the
      next patch.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      b33b7921
  3. 01 10月, 2010 3 次提交
    • C
      hfsplus: add missing extent locking in hfsplus_write_inode · 7fcc99f4
      Christoph Hellwig 提交于
      Most of the extent handling code already does proper SMP locking, but
      hfsplus_write_inode was calling into hfsplus_ext_write_extent without
      taking the extents_lock.  Fix this by splitting hfsplus_ext_write_extent
      into an internal helper that expects the lock, and a public interface
      that first acquires it.
      
      Also add a few locking asserts and document the locking rules in
      hfsplus_fs.h.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      7fcc99f4
    • C
      hfsplus: fix HFSPLUS_I calling convention · 6af502de
      Christoph Hellwig 提交于
      HFSPLUS_I doesn't return a pointer to the hfsplus-specific inode
      information like all other FOO_I macros, but dereference the pointer in a way
      that made it look like a direct struct derefence.  This only works as long
      as the HFSPLUS_I macro is used directly and prevents us from keepig a local
      hfsplus_inode_info pointer.  Fix the calling convention and introduce a local
      hip variable in all functions that use it constantly.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      6af502de
    • C
      hfsplus: fix HFSPLUS_SB calling convention · dd73a01a
      Christoph Hellwig 提交于
      HFSPLUS_SB doesn't return a pointer to the hfsplus-specific superblock
      information like all other FOO_SB macros, but dereference the pointer in a way
      that made it look like a direct struct derefence.  This only works as long
      as the HFSPLUS_SB macro is used directly and prevents us from keepig a local
      hfsplus_sb_info pointer.  Fix the calling convention and introduce a local
      sbi variable in all functions that use it constantly.
      Signed-off-by: NChristoph Hellwig <hch@tuxera.com>
      dd73a01a
  4. 20 10月, 2008 1 次提交
  5. 26 7月, 2008 1 次提交
  6. 17 10月, 2007 1 次提交
  7. 19 1月, 2006 2 次提交
  8. 09 11月, 2005 1 次提交
    • O
      [PATCH] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason · 733482e4
      Olaf Hering 提交于
      This patch removes almost all inclusions of linux/version.h.  The 3
      #defines are unused in most of the touched files.
      
      A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is
      unfortunatly in linux/version.h.
      
      There are also lots of #ifdef for long obsolete kernels, this was not
      touched.  In a few places, the linux/version.h include was move to where
      the LINUX_VERSION_CODE was used.
      
      quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'`
      
      search pattern:
      /UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      733482e4
  9. 02 8月, 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