>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>> def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.
I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as
"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 enable this."
This would not be really true as compat interfaces have nothing to do
with this config.
I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.
-Deepa
--
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
