aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/kernel/calls.S
AgeCommit message (Collapse)Author
2006-02-16[ARM] 3338/1: old ABI compat: sys_socketcallNicolas Pitre
Patch from Nicolas Pitre Commit 99595d0237926b5aba1fe4c844a011a1ba1ee1f8 forgot to intercept sys_socketcall as well. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-08[ARM] 3308/1: old ABI compat: struct sockaddr_unNicolas Pitre
Patch from Nicolas Pitre struct sockaddr_un loses its padding with EABI. Since the size of the structure is used as a validation test in unix_mkname(), we need to change the length argument to 110 whenever it is 112. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-19[ARM] safer handling of syscall table paddingAl 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: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14[ARM] 3110/5: old ABI compat: multi-ABI syscall entry supportNicolas Pitre
Patch from Nicolas Pitre This patch adds the required code to support both user space ABIs at the same time. A second syscall table is created to include legacy ABI syscalls that need an ABI compat wrapper. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14[ARM] 3108/2: old ABI compat: statfs64 and fstatfs64Nicolas 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: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-12-17[ARM] Fix sys_sendto and sys_recvfrom 6-arg syscallsRussell King
Rather than providing more wrappers for 6-arg syscalls, arrange for them to be supported as standard. This just means that we always store the 6th argument on the stack, rather than in the wrappers. This means we eliminate the wrappers for: * sys_futex * sys_arm_fadvise64_64 * sys_mbind * sys_ipc Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-13[ARM] 2896/1: Add sys_ipc_wrapper to pass 'fifth' argument on stackGeorge G. Davis
Patch from George G. Davis As pointed out be Matthew Klahn <MKLAHN@motorola.com>, some sys_ipc() call options require six args, e.g. SEMTIMEDOP. This patch adds an ARM sys_ipc_wrapper to save the sys_ipc() 'fifth' arg on the stack. Signed-off-by: George G. Davis <gdavis@mvista.com> arch/arm/kernel/calls.S | 2 +- arch/arm/kernel/entry-common.S | 5 +++++ Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-09[ARM] sys_mbind needs wrappingRussell King
sys_mbind is a 6-arg syscall, hence needs wrapping to save the sixth argument. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-09[ARM] Add memory type based allocation syscallsRussell King
Add syscall numbers and syscall table entries for mbind, set_mempolicy and get_mempolicy. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-01[ARM] 2865/2: fix fadvise64_64 syscall argument passingNicolas 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: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-15[ARM] Add syscall stubs for inotify and ioprio system callsRobert Love
Signed-off-by: Robert Love <rml@novell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus 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!