lkml.org 
[lkml]   [2018]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2] signal: add procfd_signal() syscall
    On Sat, Dec 1, 2018 at 12:12 AM Arnd Bergmann <arnd@arndb.de> wrote:
    >
    > On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione <dancol@google.com> wrote:
    > > On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner <christian@brauner.io> wrote:
    > > > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann <arnd@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

    \
     
     \ /
      Last update: 2018-12-01 00:16    [W:2.466 / U:1.428 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site