linux-toradex.git/arch/sh/kernel/syscalls_64.S, branch v3.4.78

sh: Avoid exporting unimplemented syscalls.

2012-03-28T07:20:20+00:00

Now that userspace is making use of kernel-provided sanitized headers for
working out supported interfaces, we need to be a bit more diligent with
matching the syscall definitions with their actual wiring/support state.

In theory it shouldn't hurt anything since sys_ni_syscall will ultimately
do the right thing, but there's also not much need to lie about legacy
x86 syscalls that we've never supported.

This tightens things up a bit for uClibc at least.

Suggested-by: Carmelo Amoroso 
Acked-by: Mike Frysinger 
Signed-off-by: Paul Mundt

sh: Wire up process_vm syscalls.

2011-11-11T01:58:16+00:00

Signed-off-by: Paul Mundt

All Arch: remove linkage for sys_nfsservctl system call

2011-08-26T22:09:58+00:00

The nfsservctl system call is now gone, so we should remove all
linkage for it.

Signed-off-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Linus Torvalds

ns: Wire up the setns system call

2011-05-28T17:48:39+00:00

32bit and 64bit on x86 are tested and working.  The rest I have looked
at closely and I can't find any problems.

setns is an easy system call to wire up.  It just takes two ints so I
don't expect any weird architecture porting problems.

While doing this I have noticed that we have some architectures that are
very slow to get new system calls.  cris seems to be the slowest where
the last system calls wired up were preadv and pwritev.  avr32 is weird
in that recvmmsg was wired up but never declared in unistd.h.  frv is
behind with perf_event_open being the last syscall wired up.  On h8300
the last system call wired up was epoll_wait.  On m32r the last system
call wired up was fallocate.  mn10300 has recvmmsg as the last system
call wired up.  The rest seem to at least have syncfs wired up which was
new in the 2.6.39.

v2: Most of the architecture support added by Daniel Lezcano 
v3: ported to v2.6.36-rc4 by: Eric W. Biederman 
v4: Moved wiring up of the system call to another patch
v5: ported to v2.6.39-rc6
v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
v7: ported to Linus's latest post 2.6.39 tree.

>  arch/blackfin/include/asm/unistd.h     |    3 ++-
>  arch/blackfin/mach-common/entry.S      |    1 +
Acked-by: Mike Frysinger 

Oh - ia64 wiring looks good.
Acked-by: Tony Luck 

Signed-off-by: Eric W. Biederman 
Signed-off-by: Linus Torvalds

sh: wire up sys_sendmmsg.

2011-05-23T05:41:32+00:00

Signed-off-by: Paul Mundt

sh: wire up sys_syncfs.

2011-03-22T12:56:08+00:00

Signed-off-by: Paul Mundt

sh: Wire up new fhandle and clock_adjtime syscalls.

2011-03-17T08:01:24+00:00

Signed-off-by: Paul Mundt

sh: wire up fanotify/prlimit64 syscalls.

2010-08-16T04:51:18+00:00

Signed-off-by: Paul Mundt

sh64: wire up sys_accept4.

2010-01-19T08:00:31+00:00

sh64 on the other hand provides both direct broken out syscalls as well
as socketcall access. As there are binaries that use both socketcall has
to stay around. The current ABI prefers direct syscalls.

It was pointed out that when sys_recvmmsg was added in, sys_accept4 was
overlooked. This takes care of wiring it up.

Signed-off-by: Paul Mundt

net: Introduce recvmmsg socket syscall

2009-10-13T06:40:10+00:00

Meaning receive multiple messages, reducing the number of syscalls and
net stack entry/exit operations.

Next patches will introduce mechanisms where protocols that want to
optimize this operation will provide an unlocked_recvmsg operation.

This takes into account comments made by:

. Paul Moore: sock_recvmsg is called only for the first datagram,
  sock_recvmsg_nosec is used for the rest.

. Caitlin Bestler: recvmmsg now has a struct timespec timeout, that
  works in the same fashion as the ppoll one.

  If the underlying protocol returns a datagram with MSG_OOB set, this
  will make recvmmsg return right away with as many datagrams (+ the OOB
  one) it has received so far.

. Rémi Denis-Courmont & Steven Whitehouse: If we receive N < vlen
  datagrams and then recvmsg returns an error, recvmmsg will return
  the successfully received datagrams, store the error and return it
  in the next call.

This paves the way for a subsequent optimization, sk_prot->unlocked_recvmsg,
where we will be able to acquire the lock only at batch start and end, not at
every underlying recvmsg call.

Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller