From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 17 Nov 2017 09:58:26 +0100 (CET) From: Thomas Gleixner Subject: Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion In-Reply-To: Message-ID: References: <20171110224259.15930-1-deepa.kernel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: List-Archive: List-Post: To: Arnd Bergmann Cc: Deepa Dinamani , 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 List-ID: On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner wrote: > > On Wed, 15 Nov 2017, Deepa Dinamani wrote: > >> Would this work for everyone? > > > > Having extra config switches which are selectable by architectures and > > removed when everything is converted is definitely the right way to go. > > > > That allows you to gradually convert stuff w/o inflicting wreckage all over > > the place. > > The CONFIG_64BIT_TIME would do that nicely for the new stuff like > the conditional definition of __kernel_timespec, this one would get > removed after we convert all architectures. > > A second issue is how to control the compilation of the compat syscalls. > CONFIG_COMPAT_32BIT_TIME handles that and could be defined > in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT', > this is then just a more readable way of expressing exactly when the > functions should be built. > > For completeness, there may be a third category, depending on how > we handle things like sys_nanosleep(): Here, we want the native > sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep() > to handle the 32-bit time_t variant on both 32-bit and 64-bit targets, > but our plan is to not have a native 32-bit sys_nanosleep on 32-bit > architectures any more, as new glibc should call clock_nanosleep() > with a new syscall number instead. Should we then enclose Isn't that going to break existing userspace? Thanks tglx