1. 22 12月, 2008 1 次提交
  2. 30 4月, 2008 2 次提交
  3. 05 9月, 2007 1 次提交
    • C
      [XFS] fix ASSERT and ASSERT_ALWAYS · ee5c8023
      Christoph Hellwig 提交于
      - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now
        complains about comparisons between pointers and 0
      - add a standalone ASSERT implementation because defining it to
        ASSERT_ALWAYS means the string is expanded before the token passing
        stringification. This way we get the actual content of the
        assertion in the assfail message and don't overflow sparse's
        stringification buffer leading to sparse error messages.
      
      SGI-PV: 968555
      SGI-Modid: xfs-linux-melb:xfs-kern:29310a
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      ee5c8023
  4. 08 5月, 2007 1 次提交
  5. 10 2月, 2007 1 次提交
    • D
      [XFS] Keep stack usage down for 4k stacks by using noinline. · 7989cb8e
      David Chinner 提交于
      gcc-4.1 and more recent aggressively inline static functions which
      increases XFS stack usage by ~15% in critical paths. Prevent this from
      occurring by adding noinline to the STATIC definition.
      
      Also uninline some functions that are too large to be inlined and were
      causing problems with CONFIG_FORCED_INLINING=y.
      
      Finally, clean up all the different users of inline, __inline and
      __inline__ and put them under one STATIC_INLINE macro. For debug kernels
      the STATIC_INLINE macro uninlines those functions.
      
      SGI-PV: 957159
      SGI-Modid: xfs-linux-melb:xfs-kern:27585a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NDavid Chatterton <chatz@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      7989cb8e
  6. 09 6月, 2006 1 次提交
  7. 12 1月, 2006 1 次提交
  8. 02 11月, 2005 2 次提交
  9. 21 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