On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Wed, 15 Nov 2017, Deepa Dinamani wrote: >> > I had on concern about x32, maybe we should check >> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec >> > bits. >> >> Thanks, I think you are right. I had the check conditional on >> CONFIG_64BIT_TIME and then removed as I forgot why I added it. :) >> >> > Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would >> > it help to just leave out that part for now and unconditionally >> > define '__kernel_timespec' as 'timespec' until we are ready to >> > convert the architectures? >> >> Another approach would be to use separate configs: >> >> 1. To indicate 64 bit time_t syscall support. This will be dependent >> on architectures as CONFIG_64BIT_TIME. >> We can delete this once all architectures have provided support for this. >> >> 2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later, >> which will compile out all syscalls/ features that use 32 bit time_t. >> This can help build a y2038 safe kernel later. >> >> 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 sys_nanosleep in "#if !defined(CONFIG_64BIT_TIME) || defined(CONFIG_64BIT)", or should we try to come up with another Kconfig symbol name that expresses this better? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html