From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a01:7a0:2:106d:700::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3ydX8n1pYbzDrK2 for ; Fri, 17 Nov 2017 19:58:48 +1100 (AEDT) Date: Fri, 17 Nov 2017 09:58:26 +0100 (CET) From: Thomas Gleixner 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 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 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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