Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

From: Thomas Gleixner <tglx@linutronix.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Stefan Haberland <sth@linux.vnet.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux <sparclinux@vger.kernel.org>,
	devel@driverdev.osuosl.org,
	linux-s390 <linux-s390@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Helge Deller <deller@gmx.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	sebott@linux.vnet.ibm.com,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Will Deacon <will.deacon@arm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	oprofile-list@lists.sf.net, Catali
Subject: Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Date: Fri, 17 Nov 2017 09:58:26 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711170954000.1709@nanos> (raw)
In-Reply-To: <CAK8P3a0wxs59T1zW4ahbJXeW6QjStm0mbCFoL_RQexAa6dzh_w@mail.gmail.com>

On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.de> 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
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038