All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	cohuck@redhat.com, David Miller <davem@davemloft.net>,
	Helge Deller <deller@gmx.de>,
	devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com,
	gregkh <gregkh@linuxfoundation.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Hoeppner <hoeppner@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Julian Wiedmann
Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Wed, 29 Nov 2017 22:12:23 +0100	[thread overview]
Message-ID: <CAK8P3a2ho3S3NYp4VL7kOAk-bg3bsUmLaJJVEvNfzPoEue3v3w@mail.gmail.com> (raw)
In-Reply-To: <CABeXuvrtQfSsOipGTnfmONXS45Dqxy4_T7MAcfO4VajoSycW4w@mail.gmail.com>

On Wed, Nov 29, 2017 at 12:17 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> Right. There are three options:
>
> 1. Use two configs to identify which syscalls need not be supported by
> new architectures.
> In this case it makes sense to say LEGACY_TIME_SYSCALLS and
> COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
> I can reword the config to what you mention below.
>
> 2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
> mentioned below only.
> In this case only the native and compat functions of the below
> mentioned syscalls need to be identified by the config. I like this
> option as this clearly identifies which syscalls are deprecated and do
> not have a 64 bit counterpart. Not all architectures need to support
> turning this off.
>
> 3. If we don't need either 1 or 2, then we could stick with what we
> have today in the series as CONFIG_64BIT_TIME will be deleted and they
> only need #ifdef CONFIG_64BIT.
>
> Let me know if anyone prefers something else.

I think I prefer to have both LEGACY_TIME_SYSCALLS to guard
the native deprecated syscalls (disabled on 32-bit architectures after
the conversion, and enabled on 64-bit architectures until
we merge the next one), and COMPAT_32BIT_TIME to guard the
compat versions of both the deprecated and the non-deprecated
syscalls (enabled on all existing 32-bit architectures after the
conversion, and on 64-bit architectures if they provide a compat
mode for the former).

Those two are not symmetric, but I think those are the most
common combinations, and the Kconfig symbol helps document
what they are.

There is one more category for things like io_getevents() and
rt_sigtimedwait that also need two separate compat versions,
one for 32-bit time_t and one for 64-bit time_t, but it seems better
to deal with those case-by-case rather than introducing another
Kconfig symbol.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	cohuck@redhat.com, David Miller <davem@davemloft.net>,
	Helge Deller <deller@gmx.de>,
	devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com,
	gregkh <gregkh@linuxfoundation.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Hoeppner <hoeppner@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Julian Wiedmann <jwi@linux.vnet.ibm.com>,
	Linux API <linux-api@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	oberpar@linux.vnet.ibm.com, oprofile-list@lists.sf.net,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Robert Richter <rric@kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	sebott@linux.vnet.ibm.com,
	sparclinux <sparclinux@vger.kernel.org>,
	Stefan Haberland <sth@linux.vnet.ibm.com>,
	Ursula Braun <ubraun@linux.vnet.ibm.com>,
	Will Deacon <will.deacon@arm.com>,
	"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Wed, 29 Nov 2017 22:12:23 +0100	[thread overview]
Message-ID: <CAK8P3a2ho3S3NYp4VL7kOAk-bg3bsUmLaJJVEvNfzPoEue3v3w@mail.gmail.com> (raw)
In-Reply-To: <CABeXuvrtQfSsOipGTnfmONXS45Dqxy4_T7MAcfO4VajoSycW4w@mail.gmail.com>

On Wed, Nov 29, 2017 at 12:17 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> Right. There are three options:
>
> 1. Use two configs to identify which syscalls need not be supported by
> new architectures.
> In this case it makes sense to say LEGACY_TIME_SYSCALLS and
> COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
> I can reword the config to what you mention below.
>
> 2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
> mentioned below only.
> In this case only the native and compat functions of the below
> mentioned syscalls need to be identified by the config. I like this
> option as this clearly identifies which syscalls are deprecated and do
> not have a 64 bit counterpart. Not all architectures need to support
> turning this off.
>
> 3. If we don't need either 1 or 2, then we could stick with what we
> have today in the series as CONFIG_64BIT_TIME will be deleted and they
> only need #ifdef CONFIG_64BIT.
>
> Let me know if anyone prefers something else.

I think I prefer to have both LEGACY_TIME_SYSCALLS to guard
the native deprecated syscalls (disabled on 32-bit architectures after
the conversion, and enabled on 64-bit architectures until
we merge the next one), and COMPAT_32BIT_TIME to guard the
compat versions of both the deprecated and the non-deprecated
syscalls (enabled on all existing 32-bit architectures after the
conversion, and on 64-bit architectures if they provide a compat
mode for the former).

Those two are not symmetric, but I think those are the most
common combinations, and the Kconfig symbol helps document
what they are.

There is one more category for things like io_getevents() and
rt_sigtimedwait that also need two separate compat versions,
one for 32-bit time_t and one for 64-bit time_t, but it seems better
to deal with those case-by-case rather than introducing another
Kconfig symbol.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	cohuck@redhat.com, David Miller <davem@davemloft.net>,
	Helge Deller <deller@gmx.de>,
	devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com,
	gregkh <gregkh@linuxfoundation.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Hoeppner <hoeppner@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Julian
Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Wed, 29 Nov 2017 22:12:23 +0100	[thread overview]
Message-ID: <CAK8P3a2ho3S3NYp4VL7kOAk-bg3bsUmLaJJVEvNfzPoEue3v3w@mail.gmail.com> (raw)
In-Reply-To: <CABeXuvrtQfSsOipGTnfmONXS45Dqxy4_T7MAcfO4VajoSycW4w@mail.gmail.com>

On Wed, Nov 29, 2017 at 12:17 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> Right. There are three options:
>
> 1. Use two configs to identify which syscalls need not be supported by
> new architectures.
> In this case it makes sense to say LEGACY_TIME_SYSCALLS and
> COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
> I can reword the config to what you mention below.
>
> 2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
> mentioned below only.
> In this case only the native and compat functions of the below
> mentioned syscalls need to be identified by the config. I like this
> option as this clearly identifies which syscalls are deprecated and do
> not have a 64 bit counterpart. Not all architectures need to support
> turning this off.
>
> 3. If we don't need either 1 or 2, then we could stick with what we
> have today in the series as CONFIG_64BIT_TIME will be deleted and they
> only need #ifdef CONFIG_64BIT.
>
> Let me know if anyone prefers something else.

I think I prefer to have both LEGACY_TIME_SYSCALLS to guard
the native deprecated syscalls (disabled on 32-bit architectures after
the conversion, and enabled on 64-bit architectures until
we merge the next one), and COMPAT_32BIT_TIME to guard the
compat versions of both the deprecated and the non-deprecated
syscalls (enabled on all existing 32-bit architectures after the
conversion, and on 64-bit architectures if they provide a compat
mode for the former).

Those two are not symmetric, but I think those are the most
common combinations, and the Kconfig symbol helps document
what they are.

There is one more category for things like io_getevents() and
rt_sigtimedwait that also need two separate compat versions,
one for 32-bit time_t and one for 64-bit time_t, but it seems better
to deal with those case-by-case rather than introducing another
Kconfig symbol.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	cohuck@redhat.com, David Miller <davem@davemloft.net>,
	Helge Deller <deller@gmx.de>,
	devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com,
	gregkh <gregkh@linuxfoundation.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Hoeppner <hoeppner@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Julian
Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Wed, 29 Nov 2017 21:12:23 +0000	[thread overview]
Message-ID: <CAK8P3a2ho3S3NYp4VL7kOAk-bg3bsUmLaJJVEvNfzPoEue3v3w@mail.gmail.com> (raw)
In-Reply-To: <CABeXuvrtQfSsOipGTnfmONXS45Dqxy4_T7MAcfO4VajoSycW4w@mail.gmail.com>

On Wed, Nov 29, 2017 at 12:17 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> Right. There are three options:
>
> 1. Use two configs to identify which syscalls need not be supported by
> new architectures.
> In this case it makes sense to say LEGACY_TIME_SYSCALLS and
> COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
> I can reword the config to what you mention below.
>
> 2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
> mentioned below only.
> In this case only the native and compat functions of the below
> mentioned syscalls need to be identified by the config. I like this
> option as this clearly identifies which syscalls are deprecated and do
> not have a 64 bit counterpart. Not all architectures need to support
> turning this off.
>
> 3. If we don't need either 1 or 2, then we could stick with what we
> have today in the series as CONFIG_64BIT_TIME will be deleted and they
> only need #ifdef CONFIG_64BIT.
>
> Let me know if anyone prefers something else.

I think I prefer to have both LEGACY_TIME_SYSCALLS to guard
the native deprecated syscalls (disabled on 32-bit architectures after
the conversion, and enabled on 64-bit architectures until
we merge the next one), and COMPAT_32BIT_TIME to guard the
compat versions of both the deprecated and the non-deprecated
syscalls (enabled on all existing 32-bit architectures after the
conversion, and on 64-bit architectures if they provide a compat
mode for the former).

Those two are not symmetric, but I think those are the most
common combinations, and the Kconfig symbol helps document
what they are.

There is one more category for things like io_getevents() and
rt_sigtimedwait that also need two separate compat versions,
one for 32-bit time_t and one for 64-bit time_t, but it seems better
to deal with those case-by-case rather than introducing another
Kconfig symbol.

        Arnd

  reply	other threads:[~2017-11-29 21:12 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 19:30 [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Deepa Dinamani
2017-11-27 19:30 ` Deepa Dinamani
2017-11-27 19:30 ` Deepa Dinamani
2017-11-27 19:30 ` Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 01/10] compat: Make compat helpers independent of CONFIG_COMPAT Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 02/10] include: Move compat_timespec/ timeval to compat_time.h Deepa Dinamani
2017-11-27 19:30   ` Deepa Dinamani
2017-11-27 19:30   ` Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 03/10] compat: enable compat_get/put_timespec64 always Deepa Dinamani
2017-12-14 23:27   ` [Y2038] " Ben Hutchings
2018-01-07 16:28     ` Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 04/10] arch: introduce CONFIG_64BIT_TIME Deepa Dinamani
2017-12-14 23:22   ` [Y2038] " Ben Hutchings
2017-11-27 19:30 ` [PATCH v2 05/10] arch: Introduce CONFIG_COMPAT_32BIT_TIME Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 06/10] posix-clocks: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec Deepa Dinamani
2017-12-15  0:11   ` [Y2038] " Ben Hutchings
2017-12-15 10:36     ` Arnd Bergmann
2017-12-15 10:36       ` Arnd Bergmann
2017-11-27 19:30 ` [PATCH v2 08/10] fix get_timespec64() for y2038 safe compat interfaces Deepa Dinamani
2017-12-15  0:21   ` [Y2038] " Ben Hutchings
2017-12-15 12:02     ` Arnd Bergmann
2017-12-17 23:51       ` Ben Hutchings
2017-12-18  5:11       ` Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 09/10] change time types to new y2038 safe __kernel_* types Deepa Dinamani
2017-11-27 19:30 ` [PATCH v2 10/10] nanosleep: change time types to " Deepa Dinamani
2017-11-27 19:30   ` Deepa Dinamani
2017-12-15  0:31   ` [Y2038] " Ben Hutchings
2017-12-15  0:31     ` Ben Hutchings
2017-11-27 21:58 ` [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Arnd Bergmann
2017-11-27 21:58   ` Arnd Bergmann
2017-11-27 21:58   ` Arnd Bergmann
2017-11-27 21:58   ` Arnd Bergmann
2017-11-27 22:29   ` Deepa Dinamani
2017-11-27 22:29     ` Deepa Dinamani
2017-11-27 22:29     ` Deepa Dinamani
2017-11-27 22:29     ` Deepa Dinamani
2017-11-28 14:17     ` Arnd Bergmann
2017-11-28 14:17       ` Arnd Bergmann
2017-11-28 14:17       ` Arnd Bergmann
2017-11-28 14:17       ` Arnd Bergmann
2017-11-28 23:17       ` Deepa Dinamani
2017-11-28 23:17         ` Deepa Dinamani
2017-11-28 23:17         ` Deepa Dinamani
2017-11-28 23:17         ` Deepa Dinamani
2017-11-29 21:12         ` Arnd Bergmann [this message]
2017-11-29 21:12           ` Arnd Bergmann
2017-11-29 21:12           ` Arnd Bergmann
2017-11-29 21:12           ` 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=CAK8P3a2ho3S3NYp4VL7kOAk-bg3bsUmLaJJVEvNfzPoEue3v3w@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=acme@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=cmetcalf@mellanox.com \
    --cc=cohuck@redhat.com \
    --cc=davem@davemloft.net \
    --cc=deepa.kernel@gmail.com \
    --cc=deller@gmx.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hoeppner@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jejb@parisc-linux.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.