# Re: \[PATCH v2\] signal: add procfd\_signal() syscall

- From: Arnd Bergmann \<arnd@arndb.de\>
- Date: 2018-12-01 10:26:21 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2018/12/146844
- Thread: https://ratatoskr.run/linux-fsdevel/2018/11/145139/t.md

```text
On Sat, Dec 1, 2018 at 12:12 AM Arnd Bergmann [ref] wrote:
>
> On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione [ref] wrote:
> > On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner [ref] wrote:
> > > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann [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
```