LKML Archive on
 help / color / Atom feed
From: Arnd Bergmann <>
To: Geert Uytterhoeven <>
Cc: Deepa Dinamani <>,
	Christoph Hellwig <>,
	Thomas Gleixner <>,
	Linux Kernel Mailing List <>,
	y2038 Mailman List <>,,
	Palmer Dabbelt <>
Subject: Re: [PATCH v2 3/7] riscv: Include asm-generic/compat.h
Date: Thu, 12 Jul 2018 15:51:10 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 12, 2018 at 2:42 PM, Geert Uytterhoeven
<> wrote:
> On Fri, Jul 6, 2018 at 1:43 PM Arnd Bergmann <> wrote:
>> On Fri, Jul 6, 2018 at 1:56 AM, Deepa Dinamani <> wrote:
>> > On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig <> wrote:
>> >> On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
>> It would be easy to rename compat_time_t, compat_timespec and
>> compat_timeval to something else if we could come up with a good
>> name for them (we already have too many variants of each of
>> them though, otherwise we end up being more confusing rather
>> than less).
> legacy_time_t etc.?

I think it should have '32' in the name, otherwise it might lead to confusion
regarding the size, as we also need legacy types that use 'long' (either
32-bit or 64-bit) seconds, besides the modern types that are always

In the previous patches, we introduced in the uapi

__kernel_timespec:     always 64-bit (both seconds and nanoseconds)
__kernel_old_timeval: replaces timeval (variable 'long' seconds/nanoseconds)

The __kernel_ prefix here signifies structures that are used in the
uapi headers and are possibly included in user space but must not
conflict with user space defined types like 'timeval' that can use either
'long' or 'long long' seconds in user space.

I would suggest we use __kernel_old_timespec for the equivalent
timespec variant (long/long) for consistency. I originally thought we
wouldn't need that one, but now it looks more likely that we do.
I still think we won't need a 64-bit '__kernel_timeval' type, but
it depends on what we do about getrusage(), getitimer() and

For the pure 32-bit types, I'd prefer 'old' over 'legacy', which is
similar to the existing  __kernel_old_dev_t, __kernel_gid_t, and
__kernel_old_uid_t types, but we don't need the __kernel_
prefix because we would not use them in uapi headers.

I don't see a need for replacing compat_time_t right now
(I may be missing something I had in mind earlier), but
for timespec/timeval/itimerspec, how about old_timespec32,
old_timeval32 and old_itimerspec32 to replace
compat_timespec, compat_timeval and compat_itimerspec?

For itimerval, we probably need a __kernel_old_itimerval,
but no __kernel_itimerval or old_itimerval, similar to what we
do for timeval.


  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 21:35 [PATCH v2 0/7] Introduce struct __kernel_timex Deepa Dinamani
2018-07-05 21:35 ` [PATCH v2 1/7] arm64: Make basic compat_* types always available Deepa Dinamani
2018-07-05 21:35 ` [PATCH v2 2/7] sparc: Make thread_info.h available directly Deepa Dinamani
2018-07-05 21:36 ` [PATCH v2 3/7] riscv: Include asm-generic/compat.h Deepa Dinamani
2018-07-05 22:21   ` Christoph Hellwig
2018-07-05 23:56     ` Deepa Dinamani
2018-07-06 11:42       ` Arnd Bergmann
2018-07-07  4:23         ` Deepa Dinamani
2018-07-12  8:32         ` Christoph Hellwig
2018-07-12 12:31           ` Arnd Bergmann
2018-07-12 12:42         ` Geert Uytterhoeven
2018-07-12 13:51           ` Arnd Bergmann [this message]
2018-07-05 21:36 ` [PATCH v2 4/7] timex: prepare compat helpers for y2038 changes Deepa Dinamani
2018-07-05 21:36 ` [PATCH v2 5/7] time: Add struct __kernel_timex Deepa Dinamani
2018-07-05 21:36 ` [PATCH v2 6/7] timex: use __kernel_timex internally Deepa Dinamani
2018-07-05 21:36 ` [PATCH v2 7/7] timex: change syscalls to use struct __kernel_timex Deepa Dinamani

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone