lkml.org 
[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> 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.
>
> So on a 32bit system compat_sys_nanosleep() would be the legacy
> sys_nanosleep() with the existing syscall number, but you don't want to
> introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.
>
> So back to your original question whether to use #if (MAGIC logic) or a
> separate config symbol. Please use the latter, these magic logic constructs
> are harder to read and prone to get wrong at some point. Having the
> decision logic in one place is always the right thing to do.

How about this:

config LEGACY_TIME_SYSCALLS
def_bool 64BIT || !64BIT_TIME
help
This controls the compilation of the following system calls:
time, stime,
gettimeofday, settimeofday, adjtimex, nanosleep, alarm, getitimer,
setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
These all pass 32-bit time_t arguments on 32-bit architectures and
are replaced by other interfaces (e.g. posix timers and clocks, statx).
C libraries implementing 64-bit time_t in 32-bit architectures have to
implement the handles by wrapping around the newer interfaces.
New architectures should not explicitly disable this.

Arnd

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