Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
Thomas Gleixner <[email protected]>
| Newsgroups | gmane.linux.kernel.year-2038,gmane.linux.ports.mips.general,gmane.linux.ports.sparc,gmane.linux.oprofile,gmane.linux.kernel.cross-arch,gmane.linux.ports.parisc,gmane.linux.kernel,gmane.linux.kernel.api,gmane.linux.ports.ppc64.devel |
|---|---|
| Message-ID | <alpine.DEB.2.20.1711170954000.1709@nanos> |
On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <[email protected]> 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 [email protected] https://lists.linaro.org/mailman/listinfo/y2038