On December 1, 2018 12:12:53 PM GMT+13:00, Arnd Bergmann <arnd@xxxxxxxx> wrote: >On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione <dancol@xxxxxxxxxx> >wrote: >> On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner ><christian@xxxxxxxxxx> wrote: >> > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann ><arnd@xxxxxxxx> 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. Right, I remember you pointing this out in a prior mail. Thanks for working on this for such a long time now, Arnd! Can we agree to move on with the procfd syscall given the current constraints? I just don't want to see the syscall being blocked by a generic problem whose ultimate solution is to get rid of weird architectural constraints. :)
