Doug / smarc-fsl-linux-kernel

24 Jun, 2005

4 commits

  • ceffc0785   [PATCH] xip: fs/mm: execute in place ... Browse Code »

    - generic_file* file operations do no longer have a xip/non-xip split
    - filemap_xip.c implements a new set of fops that require get_xip_page
    aop to work proper. all new fops are exported GPL-only (don't like to
    see whatever code use those except GPL modules)
    - __xip_unmap now uses page_check_address, which is no longer static
    in rmap.c, and defined in linux/rmap.h
    - mm/filemap.h is now much more clean, plainly having just Linus'
    inline funcs moved here from filemap.c
    - fix includes in filemap_xip to make it build cleanly on i386

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

    Carsten Otte
     
  • fed2fc18a   [PATCH] sys_open() cleanup ... Browse Code »

    Clean up tortured logic in sys_open().

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

    Telemaque Ndizihiwe
     
  • 45778ca81   [PATCH] Remove f_error field from struct file ... Browse Code »

    The following patch removes the f_error field and all checks of f_error.

    Trond said:

    f_error was introduced for NFS, and made sense when we were guaranteed
    always to have a file pointer around when write errors occurred. Since
    then, we have (for various reasons) had to introduce the nfs_open_context in
    order to track the file read/write state, and it made sense to move our
    f_error tracking there too.

    Signed-off-by: Christoph Lameter
    Acked-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • ef3daeda7   [PATCH] Don't force O_LARGEFILE for 32 bit processes on ia64 ... Browse Code »

    In ia64 kernel, the O_LARGEFILE flag is forced when opening a file. This
    is problematic for execution of 32 bit processes, which are not largefile
    aware, either by SW emulation or by HW execution.

    For such processes, the problem is two-fold:

    1) When trying to open a file that is larger than 4G
    the operation should fail, but it's not
    2) Writing to offset larger than 4G should fail, but
    it's not

    The proposed patch takes advantage of the way 32 bit processes are
    identified in ia64 systems. Such processes have PER_LINUX32 for their
    personality. With the patch, the ia64 kernel will not enforce the
    O_LARGEFILE flag if the current process has PER_LINUX32 set. The behavior
    for all other architectures remains unchanged.

    Signed-off-by: Yoav Zach
    Acked-by: Tony Luck
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yoav Zach
     

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