lkml.org 
[lkml]   [2018]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime
    On Fri, Jun 22, 2018 at 7:45 PM, Eric W. Biederman
    <ebiederm@xmission.com> wrote:
    > Ingo Molnar <mingo@kernel.org> writes:
    >
    > So I suspect the simplest thing to do would be to set a flag in the
    > idtype member of waitid that says give me rusage64 and then we would
    > be done.

    It would have to be a flag in both the 'idtype' field of waitid(), and also
    'who' field of getrusage(), which unfortunately uses a separate set of
    flags. Not hard to do, but still a bit more complexity.

    > Alternately we could use the low bits of the resource usage
    > pointer. Assuming we don't want to introduce another syscall that is.
    > I really don't see much incremental extensibility potential in the wait
    > or rusage interface right now.

    This is also my conclusion after looking at how various other
    operating systems implement getrusage() and wait4() today.
    It seems that this is one of the most stable APIs, everyone uses
    exactly the same structure layout (Linux/x32 being one exception,
    they have the 64-bit Linux compatible layout using __s64 instead of
    long members).

    For the other ~20 system calls we introduce for y2038, the general
    idea has been to stay mostly compatible with the source level interface,
    just using a new syscall number. statx() is a notable exception here,
    with clock_adjtime() and getitimer()/setitimer() still being undecided.

    If we don't do an extensible layout or any other new fields, there
    are still the open questions about whether any types should change:

    - changing everything to 64-bit would allow sharing the kernel
    code between compat and native
    - changing only __old_kernel_timeval to new 64-bit timeval would
    be the simplest user space change (only the syscall number
    changes with sizeof(time_t)), avoiding an extra copy thorough
    the user space stack.
    - changing timeval to (64-bit) timespec would seem the most
    sensible update, since it avoids the silly nanosecond-to-
    microsecond conversion in the kernel (glibc would still need
    to do it for compatibility). This is what I'm considering for
    getitimer/setitimer, too.

    Arnd

    \
     
     \ /
      Last update: 2018-06-25 13:43    [W:8.233 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site