From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Date: Tue, 28 Nov 2017 15:17:26 +0100 Message-ID: References: <20171127193037.8711-1-deepa.kernel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Thomas Gleixner , John Stultz , Linux Kernel Mailing List , y2038 Mailman List , Arnaldo Carvalho de Melo , Benjamin Herrenschmidt , Christian Borntraeger , Catalin Marinas , Chris Metcalf , cohuck@redhat.com, David Miller , Helge Deller , devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com, gregkh , Heiko Carstens , Jan Hoeppner , "H. Peter Anvin" , "James E.J. Bottomley" , Julian Wiedmann To: Deepa Dinamani Return-path: In-Reply-To: List-ID: List-Id: linux-parisc.vger.kernel.org On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani wrote: >>> 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. I think doing this separately would be good, I don't see any interdependency with the other patches, we just need to decide what we want in the long run. I agree my text that you cited doesn't capture the situation correctly, as this is really about the obsolete system calls that take 64-bit time_t arguments on architectures that are converted to allow 64-bit time_t for non-obsolete system calls. Maybe it's better to just reword this to "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 are all replaced by other interfaces (e.g. posix timers and clocks, statx) on architectures that got converted from 32-bit time_t to 64-bit time_t. 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." That would clarify that it's not about the compat system calls, while also allowing the two options to be set independently. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752556AbdK1ORe (ORCPT ); Tue, 28 Nov 2017 09:17:34 -0500 Received: from mail-ot0-f194.google.com ([74.125.82.194]:45877 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752259AbdK1OR2 (ORCPT ); Tue, 28 Nov 2017 09:17:28 -0500 X-Google-Smtp-Source: AGs4zMY0NLif33JZqn6sBVRHZs9m+L+9co6gESZ3iAd+RBsavVFM4SmhYFgBIXHdZc9KttSk8hko4AwwifZxhKB75ko= MIME-Version: 1.0 In-Reply-To: References: <20171127193037.8711-1-deepa.kernel@gmail.com> From: Arnd Bergmann Date: Tue, 28 Nov 2017 15:17:26 +0100 X-Google-Sender-Auth: YTQssOFLbGYl6XsKlDtwYxD9NFk Message-ID: Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion To: Deepa Dinamani Cc: Thomas Gleixner , John Stultz , Linux Kernel Mailing List , y2038 Mailman List , Arnaldo Carvalho de Melo , Benjamin Herrenschmidt , Christian Borntraeger , Catalin Marinas , Chris Metcalf , cohuck@redhat.com, David Miller , Helge Deller , devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com, gregkh , Heiko Carstens , Jan Hoeppner , "H. Peter Anvin" , "James E.J. Bottomley" , Julian Wiedmann , Linux API , linux-arch , "open list:RALINK MIPS ARCHITECTURE" , Parisc List , linuxppc-dev , linux-s390 , Mark Rutland , Ingo Molnar , Michael Ellerman , oberpar@linux.vnet.ibm.com, oprofile-list@lists.sf.net, Paul Mackerras , Peter Zijlstra , Ralf Baechle , Steven Rostedt , Robert Richter , Martin Schwidefsky , sebott@linux.vnet.ibm.com, sparclinux , Stefan Haberland , Ursula Braun , Will Deacon , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani wrote: >>> 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. I think doing this separately would be good, I don't see any interdependency with the other patches, we just need to decide what we want in the long run. I agree my text that you cited doesn't capture the situation correctly, as this is really about the obsolete system calls that take 64-bit time_t arguments on architectures that are converted to allow 64-bit time_t for non-obsolete system calls. Maybe it's better to just reword this to "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 are all replaced by other interfaces (e.g. posix timers and clocks, statx) on architectures that got converted from 32-bit time_t to 64-bit time_t. 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." That would clarify that it's not about the compat system calls, while also allowing the two options to be set independently. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Date: Tue, 28 Nov 2017 15:17:26 +0100 Message-ID: References: <20171127193037.8711-1-deepa.kernel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: sparclinux-owner@vger.kernel.org To: Deepa Dinamani Cc: Thomas Gleixner , John Stultz , Linux Kernel Mailing List , y2038 Mailman List , Arnaldo Carvalho de Melo , Benjamin Herrenschmidt , Christian Borntraeger , Catalin Marinas , Chris Metcalf , cohuck@redhat.com, David Miller , Helge Deller , devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com, gregkh , Heiko Carstens , Jan Hoeppner , "H. Peter Anvin" , "James E.J. Bottomley" , Julian List-Id: linux-api@vger.kernel.org On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani wrote: >>> 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. I think doing this separately would be good, I don't see any interdependency with the other patches, we just need to decide what we want in the long run. I agree my text that you cited doesn't capture the situation correctly, as this is really about the obsolete system calls that take 64-bit time_t arguments on architectures that are converted to allow 64-bit time_t for non-obsolete system calls. Maybe it's better to just reword this to "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 are all replaced by other interfaces (e.g. posix timers and clocks, statx) on architectures that got converted from 32-bit time_t to 64-bit time_t. 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." That would clarify that it's not about the compat system calls, while also allowing the two options to be set independently. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Tue, 28 Nov 2017 14:17:26 +0000 Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Message-Id: List-Id: References: <20171127193037.8711-1-deepa.kernel@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Deepa Dinamani Cc: Thomas Gleixner , John Stultz , Linux Kernel Mailing List , y2038 Mailman List , Arnaldo Carvalho de Melo , Benjamin Herrenschmidt , Christian Borntraeger , Catalin Marinas , Chris Metcalf , cohuck@redhat.com, David Miller , Helge Deller , devel@driverdev.osuosl.org, gerald.schaefer@de.ibm.com, gregkh , Heiko Carstens , Jan Hoeppner , "H. Peter Anvin" , "James E.J. Bottomley" , Julian On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani wrote: >>> 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. I think doing this separately would be good, I don't see any interdependency with the other patches, we just need to decide what we want in the long run. I agree my text that you cited doesn't capture the situation correctly, as this is really about the obsolete system calls that take 64-bit time_t arguments on architectures that are converted to allow 64-bit time_t for non-obsolete system calls. Maybe it's better to just reword this to "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 are all replaced by other interfaces (e.g. posix timers and clocks, statx) on architectures that got converted from 32-bit time_t to 64-bit time_t. 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." That would clarify that it's not about the compat system calls, while also allowing the two options to be set independently. Arnd