lkml.org 
[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
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?

Thanks

tglx

\
 
 \ /
  Last update: 2017-11-17 17:19    [W:0.123 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site