On Sat, Dec 1, 2018 at 12:12 AM Arnd Bergmann [off-list ref] wrote:

On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione [off-list ref] wrote:

quoted

On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner [off-list ref] wrote:

quoted

On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann [off-list ref] wrote:

One humble point I would like to make is that what I care about most is a sensible way forward without having to redo essential parts of how syscalls work.
I don't want to introduce a sane, small syscall that ends up breaking all over the place because we decided to fix past mistakes that technically have nothing to do with the patch itself.
However, I do sympathize and understand these concerns.

IMHO, it's fine to just replicate all the splits we have for the
existing signal system calls. It's ugly, but once it's done, it'll be
done for a long time. I can't see a need to add even more signal
system calls after this one.

We definitely need waitid_time64() and rt_sigtimedwait_time64()
in the very near future.

To clarify: we probably don't need rt_sigtimedwait_time64() for
x32, as it already has a 64-bit time_t. We might need waitid_time64()
or something similar though, since the plan now is to change the
time resolution for rusage to nanoseconds (__kernel_timespec)
now. The exact behavior and name of waitid_time64() is still
a matter of discussion.

       Arnd