On Fri, Nov 30, 2018 at 3:40 PM Christian Brauner <christian@xxxxxxxxxx> wrote: > > 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. Creating and using a copy_siginfo_from_user64() function would work for everyone, no?
