tree f5709253c9ccaac1df4be106b3565df0e2c1a37a
parent 640c7c9edfa2ccce17d45b215d26f15eeb6bc135
author Arnd Bergmann <arnd@arndb.de> 1547120711 +0100
committer Arnd Bergmann <arnd@arndb.de> 1547137655 +0100

y2038: add 64-bit time_t syscalls to all 32-bit architectures

This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.

This gets us to the point of being able to safely use a C library
that has 64-bit time_t in user space. There are still a couple of
loose ends to tie up in various areas of the code, but this is the
big one, and should be entirely uncontroversial at this point.

In particular, there are four system calls (getitimer, setitimer,
waitid, and getrusage) that don't have a 64-bit counterpart yet,
but these can all be safely implemented in the C library by wrapping
around the existing system calls because the 32-bit time_t they
pass only counts elapsed time, not time since the epoch. They
will be dealt with later.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The one point that still needs to be agreed on is the actual
number assignment. Following the earlier patch that added
the sysv IPC calls with common numbers where possible, I also
tried the same here, using consistent numbers on all 32-bit
architectures.

There are a couple of minor issues with this:

- On asm-generic, we now leave the numbers from 295 to 402
  unassigned, which wastes a small amount of kernel .data
  segment. Originally I had asm-generic start at 300 and
  everyone else start at 400 here, which was also not
  perfect, and we have gone beyond 400 already, so I ended
  up just using the same numbers as the rest here.

- Once we get to 512, we clash with the x32 numbers (unless
  we remove x32 support first), and probably have to skip
  a few more. I also considered using the 512..547 space
  for 32-bit-only calls (which never clash with x32), but
  that also seems to add a bit of complexity.

- On alpha, we have already used up the space up to 527
  (with a small hole between 261 and 299). We could sync
  up with that as well, but my feeling was that alpha syscalls
  are already special enough that I don't care.

Let me know if you have other ideas.