On Fri, Nov 10, 2017 at 11:42 PM, Deepa Dinamani <deepa.kernel@xxxxxxxxx> wrote: > The series is a preparation series for individual architectures > to use 64 bit time_t syscalls in compat and 32 bit emulation modes. > > This is a follow up to the series Arnd Bergmann posted: > https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html > > Big picture is as per the lwn article: > https://lwn.net/Articles/643234/ > > The series is directed at converting posix clock syscalls: > clock_gettime, clock_settime, clock_getres and clock_nanosleep > to use a new data structure __kernel_timespec at syscall boundaries. > __kernel_timespec maintains 64 bit time_t across all execution modes. > > vdso will be handled as part of each architecture when they enable > support for 64 bit time_t. > > The compat syscalls are repurposed to provide backward compatibility > by using them as native syscalls as well for 32 bit architectures. > They will continue to use timespec at syscall boundaries. > > CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec > or timespec at syscall boundaries. > > The series does the following: > 1. Enable compat syscalls unconditionally. > 2. Add a new __kernel_timespec type to be used as the data structure > for all the new syscalls. > 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in > [1] and [2] to switch to new definition of __kernel_timespec. It is > the same as struct timespec otherwise. > > Arnd Bergmann (1): > y2038: introduce CONFIG_64BIT_TIME The series looks good to me overall, and I've added it to my build-testing tree to see if it shows any regressions in random configurations. I had on concern about x32, maybe we should check for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec bits. 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? Arnd _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
