From: Paul Eggert <eggert@cs.ucla.edu>
To: Arnd Bergmann <arnd@arndb.de>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: y2038@lists.linaro.org, libc-alpha@sourceware.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org,
Albert ARIBAUD <albert.aribaud@3adev.fr>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
linux-alpha@vger.kernel.org
Subject: Re: [PATCH 3/3] y2038: rusage: use __kernel_old_timeval for process times
Date: Mon, 27 Nov 2017 09:52:06 -0800 [thread overview]
Message-ID: <34369a6e-e0ce-fe7b-65e3-9c4a33e4789a@cs.ucla.edu> (raw)
In-Reply-To: <20171127170121.634826-3-arnd@arndb.de>
On 11/27/2017 09:00 AM, Arnd Bergmann wrote:
> b) Extend the approach taken by the x32 ABI, and use the 64-bit
> native structure layout for rusage on all architectures with new
> system calls that is otherwise compatible. A possible problem here
> is that we end up with incompatible definitions of rusage between
> /usr/include/linux/resource.h and /usr/include/bits/resource.h
>
> c) Change the definition of struct rusage to be independent of
> time_t. This is the easiest change, as it does not involve new system
> call entry points, but it has the risk of introducing compile-time
> incompatibilities with user space sources that rely on the type
> of ru_utime and ru_stime.
>
> I'm picking approch c) for its simplicity, but I'd like to hear from
> others whether they would prefer a different approach.
(c) would break programs like GNU Emacs, which copy ru_utime and
ru_stime members into struct timeval variables.
All in all, (b) sounds like it would be better for programs using glibc,
as it's more compatible with what POSIX apps expect. Though I'm not sure
what problems are meant by "possible ... incompatible definitions";
perhaps you could elaborate.
next prev parent reply other threads:[~2017-11-27 17:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 17:00 [PATCH 1/3] y2038: introduce struct __kernel_old_timeval Arnd Bergmann
2017-11-27 17:00 ` [PATCH 2/3] y2038: elfcore: use __kernel_old_timeval for process times Arnd Bergmann
2017-11-27 17:00 ` [PATCH 3/3] y2038: rusage: " Arnd Bergmann
2017-11-27 17:52 ` Paul Eggert [this message]
2017-11-27 18:49 ` Eric W. Biederman
2017-11-27 20:41 ` Arnd Bergmann
2017-11-28 10:32 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34369a6e-e0ce-fe7b-65e3-9c4a33e4789a@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=akpm@linux-foundation.org \
--cc=albert.aribaud@3adev.fr \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=ebiederm@xmission.com \
--cc=fweisbec@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=ink@jurassic.park.msu.ru \
--cc=john.stultz@linaro.org \
--cc=ktkhai@virtuozzo.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=rth@twiddle.net \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®