Doug / smarc-fsl-linux-kernel

26 Jul, 2008

1 commit

  • de0ca06a9   coda: remove CODA_FS_OLD_API ... Browse Code »

    While fixing CONFIG_ leakages to the userspace kernel headers I ran into
    CODA_FS_OLD_API.

    After five years, are there still people using the old API left?
    Especially considering that you have to choose at compile time which API
    to support in the kernel (and distributions tend to offer the new API for
    some time).

    Jan: "The old API can definitely go. Around the time the new
    interface went in there were some non-Coda userspace file system
    implementations that took a while longer to convert to the new API,
    but by now they all switched to the new interface or in some cases
    to a FUSE-based solution."

    Signed-off-by: Adrian Bunk
    Acked-by: Jan Harkes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

29 Apr, 2008

1 commit

  • a2d416dcc   codafs: fix build warning ... Browse Code »

    powerpc:

    fs/coda/coda_linux.c: In function 'coda_iattr_to_vattr':
    fs/coda/coda_linux.c:137: warning: large integer implicitly truncated to unsigned type

    Cc: Jan Harkes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

27 Sep, 2006

1 commit

  • ba52de123   [PATCH] inode-diet: Eliminate i_blksize from the inode structure ... Browse Code »

    This eliminates the i_blksize field from struct inode. Filesystems that want
    to provide a per-inode st_blksize can do so by providing their own getattr
    routine instead of using the generic_fillattr() function.

    Note that some filesystems were providing pretty much random (and incorrect)
    values for i_blksize.

    [bunk@stusta.de: cleanup]
    [akpm@osdl.org: generic_fillattr() fix]
    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Theodore Ts'o
     

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