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 10:54:07 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711171049180.1709@nanos> (raw)
In-Reply-To: <CAK8P3a3fcVKTwoqN0CxYchzcFqUZPBeko=oYsA9eNxu4bQoYyw@mail.gmail.com>

On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > 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?
> 
> No, syscall that existing 32-bit user space enters would be handled by
> compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
> point. The idea here is to make the code path more uniform between
> 32-bit and 64-bit kernels.

So on a 32bit system compat_sys_nanosleep() would be the legacy
sys_nanosleep() with the existing syscall number, but you don't want to
introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.

So back to your original question whether to use #if (MAGIC logic) or a
separate config symbol. Please use the latter, these magic logic constructs
are harder to read and prone to get wrong at some point. Having the
decision logic in one place is always the right thing to do.

Thanks,

	tglx
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038