Re: [PATCH 1/2] Deprecate sysctl syscall interface

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 30/04/2018 17:33, Zack Weinberg wrote:
> (I didn't intend for any of this thread to be in private.  Sorry about
> that.  I'm not trimming any quotes to provide libc-alpha with as much
> context as possible.)
> 
> On Mon, Apr 30, 2018 at 4:25 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 30/04/2018 17:10, Zack Weinberg wrote:
>>> On Mon, Apr 30, 2018 at 3:23 PM, Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:Why?
>>>> The idea you are proposing was the original patch I sent, however I tend
>>>> to agree more with Joseph where symbol deprecation should not add newer
>>>> symbols (which would require for ports that do not return -1/ENOSYS).
>>>
>>> Why would it require that?  I don't see any reason not to use the
>>> "always return -1/ENOSYS" symbol for everything.  Where the system
>>> call exists, it already unconditionally fails, doesn't it?  So there's
>>> no observable behavior change.
>>
>> Current Linux still provides the syscall on some architecture. This is an
>> output of an script I have that check if the __NR_<syscall> can be build
>> against a toolchain (this one configured against a 3.2 kernel one or the
>> minimum one for the architectures, 3.7 for aarch64 for instance):
>>
>> SYSCALL: _sysctl
>>                aarch64: FAIL
>>                  alpha: OK
>>                    arm: OK
>>                   hppa: OK
>>                   i686: OK
>>                   ia64: OK
>>                   m68k: OK
>>             microblaze: OK
>>                   mips: OK
>>                 mips64: OK
>>             mips64-n32: OK
>>                  nios2: FAIL
>>                powerpc: OK
>>              powerpc64: OK
>>             powerpcspe: OK
>>                riscv64: FAIL
>>                   s390: OK
>>                  s390x: OK
>>                    sh4: OK
>>                sparc64: OK
>>                sparcv9: OK
>>                 tilegx: FAIL
>>                 x86_64: OK
>>             x86_64-x32: FAIL
>>
>> For the architectures that still provides it, the kernel deprecation is still
>> only printing a kernel warning the symbols is deprecated and it might be removed
>> in the future.  So we still need to provide a compat symbol with old semantic
>> and if the idea is to now return -1/ENOSYS add a new symbol on 2.28.
> 
> IMHO this means we should not deprecate sysctl in our code until the
> kernel does remove it entirely.

My view for deprecate sysctl on glibc is summarized as:

  * the deprecation in kernel occurred 10 years ago.

  * the kernel kernel/sysctl_binary.c was changed to be a compatibility wrapper 
    around /proc/sys (26a7034b40), the changes were only to *remove* deprecated
    fields and no new fields were added since then, meaning sysctl just
    provides a subset of /proc/sys (with unknown exceptions of 
    NET_IPV6_ACCEPT_RA_FROM_LOCAL (d93331965) and KERN_PANIC_ON_WARN (9e3961a097).

  * new ports do not provide the syscall (aarch64, nios2, riscv64, x86_64-x32)
    so portable programs should not rely on it.

  * although linux and bsd do share some object names, most are Linux specific
    and some vary between kernel versions and not all are properly documented.

  * sysctl for procps already uses /proc/sys.

  * this syscall is still available for architecture that support it thought
    syscall(...) (sysctl(2) manual shows the expected abi).

So I would like to hear if we should either continue to provide sysctl glibc
implementation (which differ slight than kernel signature) or if we should
deprecate.  If deprecation is the prefered way we can either by removing the
symbol for new ports while adding a compat symbol or by adding a link warning
stating it deprecated and should be removed in future releases.