Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 13 10月, 2005 1 次提交
  3. 05 10月, 2005 2 次提交
  5. 24 9月, 2005 2 次提交
  7. 22 9月, 2005 1 次提交
  9. 20 9月, 2005 4 次提交
  11. 19 9月, 2005 1 次提交
  13. 14 9月, 2005 1 次提交
  15. 10 9月, 2005 2 次提交
  17. 09 9月, 2005 1 次提交
  19. 08 9月, 2005 1 次提交
  21. 05 9月, 2005 2 次提交
  23. 04 9月, 2005 1 次提交
  25. 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
  27. 31 8月, 2005 1 次提交
  29. 30 8月, 2005 1 次提交
    • S
      [PATCH] convert signal handling of NODEFER to act like other Unix boxes. · 69be8f18
      由 Steven Rostedt 提交于 
      It has been reported that the way Linux handles NODEFER for signals is
not consistent with the way other Unix boxes handle it.  I've written a
program to test the behavior of how this flag affects signals and had
several reports from people who ran this on various Unix boxes,
confirming that Linux seems to be unique on the way this is handled.

The way NODEFER affects signals on other Unix boxes is as follows:

1) If NODEFER is set, other signals in sa_mask are still blocked.

2) If NODEFER is set and the signal is in sa_mask, then the signal is
still blocked. (Note: this is the behavior of all tested but Linux _and_
NetBSD 2.0 *).

The way NODEFER affects signals on Linux:

1) If NODEFER is set, other signals are _not_ blocked regardless of
sa_mask (Even NetBSD doesn't do this).

2) If NODEFER is set and the signal is in sa_mask, then the signal being
handled is not blocked.

The patch converts signal handling in all current Linux architectures to
the way most Unix boxes work.

Unix boxes that were tested:  DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.

* NetBSD was the only other Unix to behave like Linux on point #2. The
main concern was brought up by point #1 which even NetBSD isn't like
Linux.  So with this patch, we leave NetBSD as the lonely one that
behaves differently here with #2.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69be8f18
  31. 24 8月, 2005 1 次提交
  33. 15 8月, 2005 1 次提交
  35. 10 8月, 2005 1 次提交
  37. 05 8月, 2005 1 次提交
  39. 29 7月, 2005 1 次提交
  41. 27 7月, 2005 1 次提交
  43. 18 7月, 2005 1 次提交
  45. 16 7月, 2005 1 次提交
  47. 12 7月, 2005 3 次提交
  49. 07 7月, 2005 1 次提交
  51. 04 7月, 2005 1 次提交
  53. 01 7月, 2005 1 次提交
  55. 30 6月, 2005 2 次提交
  57. 29 6月, 2005 1 次提交
  59. 28 6月, 2005 1 次提交