This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Deprecate sysctl syscall interface
(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.
>> (If there are architectures where the system call _doesn't_ already
>> unconditionally fail, then I think we should leave sysctl alone for as
>> long as that remains true.)
>
> This patch is exactly to not provide access though glibc for this syscall.
> User still can access it though syscall().
I do not think we should remove access through glibc to any syscall
that does something useful on at least one architecture that glibc
supports.
(I also think we should _add_ access through glibc to all of the
syscalls that we currently don't.)
>>> Also, AC_CHECK_FUNC will still correctly fail for sysctl check since
>>> linkage will fail with undefined symbol (just double checked on a chroot
>>> environment), which the advantage imho this will be explicit for builds
>>> that do not use autoconf.
>>
>> This is an argument for scrapping the stubs mechanism altogether, but
>> as long as we have it, it should be used consistently.
>
>>> Also, your suggestion:
>>>
>>>> - Drop sysdeps/u/s/l/sysctl.c as in this patch, but move
>>>> sysdeps/u/s/l/generic/sysctl.c to misc/, and *don't* make it a compat
>>>> symbol.
>>>
>>> Will incur in a new symbol for non Linux targets, which I think it is not
>>> the desirable action.
>>
>> A major part of my point here is that I think it _would be_
>> appropriate to make sysctl() part of the generic glibc API surface,
>> despite Linux refusing to support it. There are more non-Linux
>> operating systems that support it (e.g. all of the BSDs) than don't
>> (e.g. Hurd).
>>
>> Again, if we scrapped the stubs mechanism (so system primitives that
>> aren't available on some targets wouldn't be defined at all) then my
>> opinion would change.
>
> We can follow up this on libc-alpha, but since it has been deprecated over
> 10 years on Linux and there is no upcoming port for non Linux target besides
> Hurd I really think there is little to no gain to continue support a really
> problematic ABI (at least from Linux side).