On Fri, 17 Nov 2017, Arnd Bergmann wrote:
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.
s/handles/handling/ ????
New architectures should not explicitly disable this.
New architectures should never enable this, right?
Thanks,
tglx