On Fri, Jun 22, 2018 at 7:45 PM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> Ingo Molnar <mingo@xxxxxxxxxx> 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
