09 Feb, 2008

1 commit


01 Feb, 2008

1 commit


29 Oct, 2007

1 commit

  • Use of ptrdiff_t in places like

    - if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
    + if (!access_ok(VERIFY_WRITE, (u8 __user *)
    + (ptrdiff_t) u_tmp->rx_buf,
    + u_tmp->len))

    is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
    we are not even promised that ptrdiff_t is large enough to hold a pointer,
    just enough to hold a difference between two pointers within the same object).
    For another, it confuses the fsck out of sparse.

    Use unsigned long or uintptr_t instead. There are several places misusing
    ptrdiff_t; fixed.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

20 Oct, 2007

1 commit

  • define first set of BIT* macros

    - move BITOP_MASK and BITOP_WORD from asm-generic/bitops/atomic.h to
    include/linux/bitops.h and rename it to BIT_MASK and BIT_WORD
    - move BITS_TO_LONGS and BITS_PER_BYTE to bitops.h too and allow easily
    define another BITS_TO_something (e.g. in event.c) by BITS_TO_TYPE macro
    Remaining (and common) BIT macro will be defined after all occurences and
    conflicts will be sorted out in the patches.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     

05 Dec, 2006

1 commit

  • CONFIG_LBD and CONFIG_LSF are spread into asm/types.h for no particularly
    good reason.

    Centralising the definition in linux/types.h means that arch maintainers
    don't need to bother adding it, as well as fixing the problem with
    x86-64 users being asked to make a decision that has absolutely no
    effect.

    The H8/300 porters seem particularly confused since I'm not aware of any
    microcontrollers that need to support 2TB filesystems.

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Linus Torvalds

    Matthew Wilcox
     

03 Dec, 2006

2 commits


05 Oct, 2006

1 commit


01 Oct, 2006

1 commit

  • This patch defines:
    * a generic boolean-type, named 'bool'
    * aliases to 0 and 1, named 'false' and 'true'

    Removing colliding definitions of 'bool', 'false' and 'true'.

    Signed-off-by: Richard Knutsson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Knutsson
     

28 Jun, 2006

2 commits


26 Apr, 2006

1 commit


27 Mar, 2006

1 commit

  • Add blkcnt_t as the type of inode.i_blocks. This enables you to make the size
    of blkcnt_t either 4 bytes or 8 bytes on 32 bits architecture with CONFIG_LSF.

    - CONFIG_LSF
    Add new configuration parameter.
    - blkcnt_t
    On h8300, i386, mips, powerpc, s390 and sh that define sector_t,
    blkcnt_t is defined as u64 if CONFIG_LSF is enabled; otherwise it is
    defined as unsigned long.
    On other architectures, it is defined as unsigned long.
    - inode.i_blocks
    Change the type from sector_t to blkcnt_t.

    Signed-off-by: Takashi Sato
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Takashi Sato
     

02 Feb, 2006

1 commit


28 Oct, 2005

1 commit

  • Beginning of gfp_t annotations:

    - -Wbitwise added to CHECKFLAGS
    - old __bitwise renamed to __bitwise__
    - __bitwise defined to either __bitwise__ or nothing, depending on
    __CHECK_ENDIAN__ being defined
    - gfp_t switched from __nocast to __bitwise__
    - force cast to gfp_t added to __GFP_... constants
    - new helper - gfp_zone(); extracts zone bits out of gfp_t value and casts
    the result to int

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

09 Oct, 2005

1 commit

  • - added typedef unsigned int __nocast gfp_t;

    - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
    the same warnings as far as sparse is concerned, doesn't change
    generated code (from gcc point of view we replaced unsigned int with
    typedef) and documents what's going on far better.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

30 Aug, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds