Switch to using the generic compat_sys_getdents instead of a
homebrew one.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Wire up utimensat/signalfd/timerfd/eventfd syscalls and mark
select/fadvise64/utimes to be ignored by checksyscalls.sh
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Definitely unimplemented at this point and will just
trap to sys_ni_syscall...
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Signed-off-by: NGuy Martin <gmsoft@tuxicoman.be>

Move migrate_pages into the same position as specified
in unistd.h. This fixes migrate_pages, pselect6 and
ppoll syscalls.
Signed-off-by: NCarlos O'Donell <carlos@systemhalted.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

the parisc affecting portion of the patch was inadvertantly
reverted a while ago.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

- additionally update my copyright timestamps
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

And unmask the pselect6/ppoll system calls.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

I noticed that almost all architectures implemented exactly the same
sys32_sysinfo...  except parisc, where a bug was to be found in handling of
the uptime.  So let's remove a whole whack of code for fun and profit.
Cribbed compat_sys_sysinfo from x86_64's implementation, since I figured it
would be the best tested.

This patch incorporates Arnd's suggestion of not using set_fs/get_fs, but
instead extracting out the common code from sys_sysinfo.

Cc: Christoph Hellwig <hch@infradead.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

And now suddenly, linux32 works on parisc...
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Most are easy, but sync_file_range needed special handling when entering
through the 32-bit syscall table.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

compat_sys_getsockopt exists, so we should use that, instead of directly
using sys_getsockopt on 64-bit compiles.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Create compat_sys_adjtimex and use it an all appropriate places.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

parisc defines ARCH_WANT_STAT64, so we want to use fstatat64. It does not
appear that it needs to be ENTRY_COMP, because struct stat64 is the same
on both 32-bit and 64-bit (unlike on other platforms which did define a
compat_sys_fstatat64.)
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Swap out pselect6/ppoll for ni_syscall for now. We also have to switch
the macro to ENTRY_SAME since compat_sys_ni_syscall does not exist.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Wire up some new syscalls that have been merged upstream,
  o inotify
  o openat et al
  o pselect6/ppoll
  o migrate_pages
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

2.6.12-rc4-pa3 s/__LP64__/CONFIG_64BIT/ and fixup config.h usage
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

add syscall entries for ioprio_set/get as per Jens Axboe.
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!