On Sat, Dec 1, 2018 at 12:12 AM Arnd Bergmann <a...@arndb.de> wrote:
>
> On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione <dan...@google.com> wrote:
> > On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner <christ...@brauner.io>
> > wrote:
> > > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann <a...@arndb.de>
> > > 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
