1. 24 9月, 2009 1 次提交
  2. 06 9月, 2008 1 次提交
  3. 04 5月, 2008 1 次提交
    • U
      unified (weak) sys_pipe implementation · d35c7b0e
      Ulrich Drepper 提交于
      This replaces the duplicated arch-specific versions of "sys_pipe()" with
      one unified implementation.  This removes almost 250 lines of duplicated
      code.
      
      It's marked __weak, so that *if* an architecture wants to override the
      default implementation it can do so by simply having its own replacement
      version, since many architectures use alternate calling conventions for
      the 'pipe()' system call for legacy reasons (ie traditional UNIX
      implementations often return the two file descriptors in registers)
      
      I still haven't changed the cris version even though Linus says the BKL
      isn't needed.  The arch maintainer can easily do it if there are really
      no obstacles.
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d35c7b0e
  4. 17 10月, 2007 1 次提交
  5. 29 6月, 2007 1 次提交
    • D
      Introduce fixed sys_sync_file_range2() syscall, implement on PowerPC and ARM · edd5cd4a
      David Woodhouse 提交于
      Not all the world is an i386.  Many architectures need 64-bit arguments to be
      aligned in suitable pairs of registers, and the original
      sys_sync_file_range(int, loff_t, loff_t, int) was therefore wasting an
      argument register for padding after the first integer.  Since we don't
      normally have more than 6 arguments for system calls, that left no room for
      the final argument on some architectures.
      
      Fix this by introducing sys_sync_file_range2(int, int, loff_t, loff_t) which
      all fits nicely.  In fact, ARM already had that, but called it
      sys_arm_sync_file_range.  Move it to fs/sync.c and rename it, then implement
      the needed compatibility routine.  And stop the missing syscall check from
      bitching about the absence of sys_sync_file_range() if we've implemented
      sys_sync_file_range2() instead.
      
      Tested on PPC32 and with 32-bit and 64-bit userspace on PPC64.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      edd5cd4a
  6. 21 5月, 2007 1 次提交
  7. 18 12月, 2006 1 次提交
    • R
      [ARM] Add more syscalls · 5a059f1a
      Russell King 提交于
      Add:
        sys_unshare
        sys_set_robust_list
        sys_get_robust_list
        sys_splice
        sys_arm_sync_file_range
        sys_tee
        sys_vmsplice
        sys_move_pages
        sys_getcpu
      
      Special note about sys_arm_sync_file_range(), which is implemented as:
      
      asmlinkage long sys_arm_sync_file_range(int fd, unsigned int flags,
                                              loff_t offset, loff_t nbytes)
      {
              return sys_sync_file_range(fd, offset, nbytes, flags);
      }
      
      We can't export sys_sync_file_range() directly on ARM because the
      argument list someone picked does not fit in the available registers.
      Would be nice if... there was an arch maintainer review mechanism for
      new syscalls before they hit the kernel.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5a059f1a
  8. 02 10月, 2006 1 次提交
    • A
      [PATCH] rename the provided execve functions to kernel_execve · 3db03b4a
      Arnd Bergmann 提交于
      Some architectures provide an execve function that does not set errno, but
      instead returns the result code directly.  Rename these to kernel_execve to
      get the right semantics there.  Moreover, there is no reasone for any of these
      architectures to still provide __KERNEL_SYSCALLS__ or _syscallN macros, so
      remove these right away.
      
      [akpm@osdl.org: build fix]
      [bunk@stusta.de: build fix]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andi Kleen <ak@muc.de>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Hirokazu Takata <takata.hirokazu@renesas.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3db03b4a
  9. 22 3月, 2006 1 次提交
  10. 15 1月, 2006 1 次提交
  11. 05 10月, 2005 1 次提交
  12. 01 9月, 2005 1 次提交
    • N
      [ARM] 2865/2: fix fadvise64_64 syscall argument passing · 68d9102f
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      The prototype for sys_fadvise64_64() is:
          long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int advice)
      The argument list is therefore as follows on legacy ABI:
      	fd: type int (r0)
      	offset: type long long (r1-r2)
      	len: type long long (r3-sp[0])
      	advice: type int (sp[4])
      With EABI this becomes:
      	fd: type int (r0)
      	offset: type long long (r2-r3)
      	len: type long long (sp[0]-sp[4])
      	advice: type int (sp[8])
      Not only do we have ABI differences here, but the EABI version requires
      one additional word on the syscall stack.
      To avoid the ABI mismatch and the extra stack space required with EABI
      this syscall is now defined with a different argument ordering
      on ARM as follows:
          long sys_arm_fadvise64_64(int fd, int advice, loff_t offset, loff_t len)
      This gives us the following ABI independent argument distribution:
      	fd: type int (r0)
      	advice: type int (r1)
      	offset: type long long (r2-r3)
      	len: type long long (sp[0]-sp[4])
      Now, since the syscall entry code takes care of 5 registers only by
      default including the store of r4 to the stack, we need a wrapper to
      store r5 to the stack as well.  Because that wrapper was missing and was
      always required this means that sys_fadvise64_64 never worked on ARM and
      therefore we can safely reuse its syscall number for our new
      sys_arm_fadvise64_64 interface.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      68d9102f
  13. 05 5月, 2005 1 次提交
    • R
      [PATCH] ARM: Fix kernel stack offset calculations · 4f7a1812
      Russell King 提交于
      Various places in the ARM kernel implicitly assumed that kernel
      stacks are always 8K due to hard coded constants.  Replace these
      constants with definitions.
      
      Correct the allowable range of kernel stack pointer values within
      the allocation.  Arrange for the entire kernel stack to be zeroed,
      not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set.
      Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
      4f7a1812
  14. 01 5月, 2005 1 次提交
  15. 20 4月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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