Eric Lee / smarc-fsl-linux-kernel

05 Dec, 2006

1 commit

  • e62438630   [PATCH] Centralise definitions of sector_t and blkcnt_t ... Browse Code »

    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
     

26 Apr, 2006

1 commit

27 Mar, 2006

1 commit

  • a0f62ac63   [PATCH] 2TB files: add blkcnt_t ... Browse Code »

    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
     

05 Sep, 2005

1 commit

  • fa5b08d5f   [PATCH] sab: consolidate kmem_bufctl_t ... Browse Code »

    This is used only in slab.c and each architecture gets to define whcih
    underlying type is to be used.

    Seems a bit silly - move it to slab.c and use the same type for all
    architectures: unsigned int.

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

    Kyle Moffett
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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