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