On December 1, 2018 12:46:22 PM GMT+13:00, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >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? Meaning, no compat syscalls, introduce new struct siginfo64_t and the copy function you named above?
