[PATCH] Linux: Remove <sys/sysctl.h> and the sysctl function

Zack Weinberg zackw@panix.com
Wed Mar 11 18:17:06 GMT 2020


On Wed, Mar 11, 2020 at 1:16 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 08/03/2020 18:20, Florian Weimer wrote:
> > The sysctl compat function always fails with ENOSYS because even for
> > architectures which in theory support the system call, it is usually
> > disabled at kernel build time (following the kernel default).
>
> I aleady summarized my take on sysctl deprecation/removal [1], but
> Zack did not reply based on his take to not remove it [2].
>
> And, besides the deprecation done in last release, I foresee that
> the header removal will most likely break some projects. But it should
> not block this change imho.
>
> [1] https://sourceware.org/legacy-ml/libc-alpha/2018-05/msg00067.html
> [2] https://sourceware.org/legacy-ml/libc-alpha/2018-04/msg00633.html

Oof, that was a long time ago.  Let's start over.

Given that the Linux kernel maintainers have made it very clear that
they don't like their implementation of sysctl(2) and they want user
space to stop using it, I have no objection to us changing our
implementation of sysctl(3) to rely exclusively on /proc/sys and other
information sources (e.g. uname(2), getrandom(2)).

However, I think that glibc should continue to provide sysctl(3) and
should actively work to make it more like the fully-supported
sysctl(3) that the BSDs have.  It follows that we should continue to
install <sys/sysctl.h>.  It would be reasonable for us to treat
sysctlbyname() as the primary interface and provide compatibility
MIB-to-name mappings only for the set of MIB vectors that were
historically supported by Linux's sysctl(2).

zw


More information about the Libc-alpha mailing list