All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
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: Mon, 27 Nov 2017 14:29:59 -0800	[thread overview]
Message-ID: <CABeXuvrBOSVTNSbEZZMKmuTgWeU_VDqjSZkwGAM+bnPh0-72zA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2pcpQqf_TNGVxLBePBSKYhxD90UN-FjBor4d-dKhAwbQ@mail.gmail.com>

>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>>      def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as


        "This controls the compilation of the following system calls:
        time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
        setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
        These all pass 32-bit time_t arguments on 32-bit architectures and
        are replaced by other interfaces (e.g. posix timers and clocks, statx).
        C libraries implementing 64-bit time_t in 32-bit architectures have to
        implement the handles by wrapping around the newer interfaces.
        New architectures should not explicitly enable this."

This would not be really true as compat interfaces have nothing to do
with this config.

I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.

-Deepa

WARNING: multiple messages have this Message-ID (diff)
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
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: Mon, 27 Nov 2017 14:29:59 -0800	[thread overview]
Message-ID: <CABeXuvrBOSVTNSbEZZMKmuTgWeU_VDqjSZkwGAM+bnPh0-72zA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2pcpQqf_TNGVxLBePBSKYhxD90UN-FjBor4d-dKhAwbQ@mail.gmail.com>

>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>>      def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as


        "This controls the compilation of the following system calls:
        time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
        setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
        These all pass 32-bit time_t arguments on 32-bit architectures and
        are replaced by other interfaces (e.g. posix timers and clocks, statx).
        C libraries implementing 64-bit time_t in 32-bit architectures have to
        implement the handles by wrapping around the newer interfaces.
        New architectures should not explicitly enable this."

This would not be really true as compat interfaces have nothing to do
with this config.

I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.

-Deepa

WARNING: multiple messages have this Message-ID (diff)
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
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: Mon, 27 Nov 2017 14:29:59 -0800	[thread overview]
Message-ID: <CABeXuvrBOSVTNSbEZZMKmuTgWeU_VDqjSZkwGAM+bnPh0-72zA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2pcpQqf_TNGVxLBePBSKYhxD90UN-FjBor4d-dKhAwbQ@mail.gmail.com>

>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>>      def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as


        "This controls the compilation of the following system calls:
        time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
        setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
        These all pass 32-bit time_t arguments on 32-bit architectures and
        are replaced by other interfaces (e.g. posix timers and clocks, statx).
        C libraries implementing 64-bit time_t in 32-bit architectures have to
        implement the handles by wrapping around the newer interfaces.
        New architectures should not explicitly enable this."

This would not be really true as compat interfaces have nothing to do
with this config.

I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.

-Deepa

WARNING: multiple messages have this Message-ID (diff)
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
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: Mon, 27 Nov 2017 22:29:59 +0000	[thread overview]
Message-ID: <CABeXuvrBOSVTNSbEZZMKmuTgWeU_VDqjSZkwGAM+bnPh0-72zA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2pcpQqf_TNGVxLBePBSKYhxD90UN-FjBor4d-dKhAwbQ@mail.gmail.com>

>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>>      def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as


        "This controls the compilation of the following system calls:
        time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
        setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
        These all pass 32-bit time_t arguments on 32-bit architectures and
        are replaced by other interfaces (e.g. posix timers and clocks, statx).
        C libraries implementing 64-bit time_t in 32-bit architectures have to
        implement the handles by wrapping around the newer interfaces.
        New architectures should not explicitly enable this."

This would not be really true as compat interfaces have nothing to do
with this config.

I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.

-Deepa

  reply	other threads:[~2017-11-27 22:29 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 [this message]
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
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=CABeXuvrBOSVTNSbEZZMKmuTgWeU_VDqjSZkwGAM+bnPh0-72zA@mail.gmail.com \
    --to=deepa.kernel@gmail.com \
    --cc=acme@kernel.org \
    --cc=arnd@arndb.de \
    --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=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.