From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Date: Tue, 28 Nov 2017 15:17:54 -0800 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: Arnd Bergmann Return-path: In-Reply-To: List-ID: List-Id: linux-parisc.vger.kernel.org On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann wrote: > 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. 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 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. -Deepa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753302AbdK1XSC (ORCPT ); Tue, 28 Nov 2017 18:18:02 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:46580 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbdK1XR4 (ORCPT ); Tue, 28 Nov 2017 18:17:56 -0500 X-Google-Smtp-Source: AGs4zMadP/sBvkHRVd42jOND/pg1S8pNIcgTQfM0VLRrpBvHluKg8tQ3cfETCaD8kyTL0maPh2v+P+bsqgbDuVtfxaA= MIME-Version: 1.0 In-Reply-To: References: <20171127193037.8711-1-deepa.kernel@gmail.com> From: Deepa Dinamani Date: Tue, 28 Nov 2017 15:17:54 -0800 Message-ID: Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion To: Arnd Bergmann 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 Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann wrote: > 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. 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 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. -Deepa From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion Date: Tue, 28 Nov 2017 15:17:54 -0800 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: linux-parisc-owner@vger.kernel.org To: Arnd Bergmann 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 Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann wrote: > 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. 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 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. -Deepa From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Date: Tue, 28 Nov 2017 23:17:54 +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: Arnd Bergmann 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 Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann wrote: > 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. 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 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. -Deepa