1. 16 2月, 2007 1 次提交
    • R
      [ARM] 4137/1: Add kexec support · c587e4a6
      Richard Purdie 提交于
      Add kexec support to ARM.
      
      Improvements like commandline handling could be made but this patch gives
      basic functional support. It uses the next available syscall number, 347.
      
      Once the syscall number is known, userspace support will be
      finalised/submitted to kexec-tools, various patches already exist.
      
      Originally based on a patch by Maxim Syrchin but updated and forward
      ported by various people.
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c587e4a6
  2. 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
  3. 10 12月, 2006 1 次提交
  4. 17 2月, 2006 1 次提交
  5. 09 2月, 2006 1 次提交
  6. 19 1月, 2006 1 次提交
    • A
      [ARM] safer handling of syscall table padding · fa1b4f91
      Al Viro 提交于
      ARM entry-common.S needs to know syscall table size; in itself that would
      not be a problem, but there's an additional constraint - some of the
      instructions using it want a constant that would be a multiple of 4.
      So we have to pad syscall table with sys_ni_syscall and that's where
      the trouble begins.  .rept pseudo-op wants a constant expression for
      number of repetitions and subtraction of two labels (before and after
      syscall table) doesn't always get simplified to constant early enough
      for .rept.  If labels end up in different frags, we lose.  And while
      the frag size is large enough (slightly below 4Kb), the syscall table
      is about 1/3 of that.  We used to get away with that, but the recent
      changes had been enough to trigger the breakage.
      
      Proper fix is simple: have a macro (CALL(x)) to populate the table
      instead of using explicit .long x and the first time we include calls.S
      have it defined to .equ NR_syscalls,NR_syscalls+1.  Then we can find
      the proper amount of padding on the first inclusion simply by looking
      at NR_syscalls at that time.  And that will be constant, no matter what.
      
      Moreover, the same trick kills the need of having an estimate of padded
      NR_syscalls - it will be calculated for free at the same time.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fa1b4f91
  7. 15 1月, 2006 2 次提交
  8. 17 12月, 2005 1 次提交
  9. 14 9月, 2005 1 次提交
  10. 10 9月, 2005 1 次提交
  11. 09 9月, 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. 15 8月, 2005 1 次提交
  14. 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