On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
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@xxxxxxxx> --- 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.
I have a patch that I'll send soon to make x32 use its own table. As far as I'm concerned, 547 is *it*. 548 is just a normal number and is not special. But let's please not reuse 512..547 for other purposes on x86 variants -- that way lies even more confusion, IMO. --Andy
