On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
