[+Cc Florian, libc-alpha]
On Thu, Nov 14, 2019 at 11:18:15AM +0100, Arnd Bergmann wrote:
> On Thu, Nov 14, 2019 at 1:38 AM Christian Brauner
> wrote:
> > On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
> > > On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov
> > > wrote:
> > > >
>
On Thu, Nov 14, 2019 at 1:38 AM Christian Brauner
wrote:
> On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
> > On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov wrote:
> > >
> > > On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> >
> > > > ---
> > > > Question:
On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
...
>
> There are clearly too many time types at the moment, but I'm in the
> process of throwing out the ones we no longer need now.
Cool!
> I do have a number patches implementing other variants for the syscall,
> and I suppose
On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov wrote:
>
> On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> > ---
> > Question: should we also rename 'struct rusage' into 'struct
> > __kernel_rusage'
> > here, to make them completely unambiguous?
>
> The patch looks ok to me. I
On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> There are two 'struct timeval' fields in 'struct rusage'.
>
> Unfortunately the definition of timeval is now ambiguous when used in
> user space with a libc that has a 64-bit time_t, and this also changes
> the 'rusage' definition
There are two 'struct timeval' fields in 'struct rusage'.
Unfortunately the definition of timeval is now ambiguous when used in
user space with a libc that has a 64-bit time_t, and this also changes
the 'rusage' definition in user space in a way that is incompatible with
the system call
