1. 15 1月, 2006 3 次提交
    • N
      [ARM] 3109/1: old ABI compat: syscall wrappers for ABI impedance matching · 687ad019
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      The difference between EABI and the legacy ABI may affect either
      structure member alignment and/or argument register selection.
      
      The patch has the details.
      
      Included are wrappers for the following syscalls:
      
        sys_stat64
        sys_lstat64
        sys_fstat64
        sys_fcntl64
        sys_epoll_ctl
        sys_epoll_wait
        sys_ipc
        sys_semop
        sys_semtimedop
        sys_pread64
        sys_pwrite64
        sys_truncate64
        sys_ftruncate64
        sys_readahead
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      687ad019
    • N
      [ARM] 3108/2: old ABI compat: statfs64 and fstatfs64 · 713c4815
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      struct statfs64 has extra padding with EABI growing its size from 84 to
      88. This struct is now __attribute__((packed,aligned(4))) with a small
      assembly wrapper to force the sz argument to 84 if it is 88 to avoid
      copying the extra padding over user space memory unexpecting it.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      713c4815
    • N
      [ARM] 3105/4: ARM EABI: new syscall entry convention · 3f2829a3
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      For a while we wanted to change the way syscalls were called on ARM.
      Instead of encoding the syscall number in the swi instruction which
      requires reading back the instruction from memory to extract that number
      and polluting the data cache, it was decided that simply storing the
      syscall number into r7 would be more efficient. Since this represents
      an ABI change then making that change at the same time as EABI support
      is the right thing to do.
      
      It is now expected that EABI user space binaries put the syscall number
      into r7 and use "swi 0" to call the kernel. Syscall register argument
      are also expected to have "EABI arrangement" i.e. 64-bit arguments
      should be put in a pair of registers from an even register number.
      
      Example with long ftruncate64(unsigned int fd, loff_t length):
      
      	legacy ABI:
      	- put fd into r0
      	- put length into r1-r2
      	- use "swi #(0x900000 + 194)" to call the kernel
      
      	new ARM EABI:
      	- put fd into r0
      	- put length into r2-r3 (skipping over r1)
      	- put 194 into r7
      	- use "swi 0" to call the kernel
      
      Note that it is important to use 0 for the swi argument as backward
      compatibility with legacy ABI user space relies on this.
      The syscall macros in asm-arm/unistd.h were also updated to support
      both ABIs and implement the right call method automatically.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3f2829a3
  2. 17 12月, 2005 1 次提交
  3. 19 11月, 2005 1 次提交
    • D
      [ARM] 3168/1: Update ARM signal delivery and masking · a6c61e9d
      Daniel Jacobowitz 提交于
      Patch from Daniel Jacobowitz
      
      After delivering a signal (creating its stack frame) we must check for
      additional pending unblocked signals before returning to userspace.
      Otherwise signals may be delayed past the next syscall or reschedule.
      
      Once that was fixed it became obvious that the ARM signal mask manipulation
      was broken.  It was a little bit broken before the recent SA_NODEFER
      changes, and then very broken after them.  We must block the requested
      signals before starting the handler or the same signal can be delivered
      again before the handler even gets a chance to run.
      Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a6c61e9d
  4. 13 10月, 2005 1 次提交
  5. 14 9月, 2005 1 次提交
  6. 10 9月, 2005 1 次提交
  7. 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
  8. 26 4月, 2005 5 次提交
  9. 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