On Fri, Nov 17, 2017 at 11:40 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> 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/ ????
I meant "handlers".
>> New architectures should not explicitly disable this.
>
> New architectures should never enable this, right?
Right, I got an extra "not". I guess if Deepa incorporates the new option,
she can also improve my English ;-)
Arnd
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
