1. 30 Apr, 2008 1 commit
  2. 08 Feb, 2008 1 commit
    • Marcin Slusarz's avatar
      byteorder: move le32_add_cpu & friends from OCFS2 to core · 8b5f6883
      Marcin Slusarz authored
      
      This patchset moves le*_add_cpu and be*_add_cpu functions from OCFS2 to core
      header (1st), converts ext3 filesystem to this API (2nd) and replaces XFS
      different named functions with new ones (3rd).
      
      There are many places where these functions will be useful.  Just look at:
      grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]' linux-src/ Patch for
      ext3 is an example how conversions will probably look like.
      
      This patch:
      
      - move inline functions which add native byte order variable to
        little/big endian variable to core header
        * le16_add_cpu(__le16 *var, u16 val)
        * le32_add_cpu(__le32 *var, u32 val)
        * le64_add_cpu(__le64 *var, u64 val)
        * be32_add_cpu(__be32 *var, u32 val)
      - add for completeness:
        * be16_add_cpu(__be16 *var, u16 val)
        * be64_add_cpu(__be64 *var, u64 val)
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: default avatarMark Fasheh <mark.fasheh@oracle.com>
      Cc: David Chinner <dgc@sgi.com>
      Cc: Timothy Shimmin <tes@sgi.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8b5f6883
  3. 08 May, 2007 1 commit
  4. 08 Jan, 2006 1 commit
  5. 19 Sep, 2005 1 commit
  6. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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