On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner email@example.com wrote:
On Fri, 17 Nov 2017, Arnd Bergmann wrote:
On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner firstname.lastname@example.org 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.