Linux 5.5 Finally Doing Away With The SYSCTL System Call

[phoronix]

Phoronix: Linux 5.5 Finally Doing Away With The SYSCTL System Call

The Linux 5.5 kernel is set to finally eliminate the code backing the sysctl system call, which has been deprecated for about a decade and should have no impact on modern systems of any architecture...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-Kills-SYSCTL-SYSCALL

[coder]

I'll just ask the obvious question: why prefer /proc/sys/ over sysctl()?

Is the issue just that one is implemented in terms of the other, and they want to remove the glue code? I guess the function call requires one or more enums that essentially encode the nodes in the /proc/sys/ path string, and folks don't want to maintain both those enums and the actual path strings?

https://linux.die.net/man/2/sysctl

[gsedej]

Is "sysctl" conneted via REISUB commands - it's still very useful for me with buggy graphic drivers/compositors/etc ?
Also does "sysctl" enable some reading/writing from motherboard ?

[xen0n]

Is "sysctl" conneted via REISUB commands - it's still very useful for me with buggy graphic drivers/compositors/etc ?
Also does "sysctl" enable some reading/writing from motherboard ?

What you're referring to is "magic SysRq", which is a totally different beast and is not affected at all.

[drjohnnyfever]

I find it interesting that Linux and FreeBSD went in opposite directions on this. FreeBSD deprecated the procfs interface (which as far as I know is implemented with sysctl(2) on FreeBSD) and Linux deprecated sysctl in favor of procfs.

[F.Ultra]

I'll just ask the obvious question: why prefer /proc/sys/ over sysctl()?

Is the issue just that one is implemented in terms of the other, and they want to remove the glue code? I guess the function call requires one or more enums that essentially encode the nodes in the /proc/sys/ path string, and folks don't want to maintain both those enums and the actual path strings?

https://linux.die.net/man/2/sysctl

Looking at the original announcement from 2010 Eric Biederman states these reasons:

*Binary sysctls are a long standing source of subtle kernel bugs and security issues.

*The man page for sysctl(2) documents it as unusable for user space programs.

*sysctl(2) is not generally ABI compatible to a 32bit user space application on a 64bit and a 32bit kernel.

[Jabberwocky]

Looking at Linux sysctl.c I notice: Added /proc support, Dec 1995 That's a while ago.

I find it interesting that Linux and FreeBSD went in opposite directions on this. FreeBSD deprecated the procfs interface (which as far as I know is implemented with sysctl(2) on FreeBSD) and Linux deprecated sysctl in favor of procfs.

I guess FreeBSD does not agree with "Mike Gancarz: The UNIX Philosophy" ?

Using procfs for userland interaction makes much more sense to me. For example (programmatically) explore, monitor, and change specific values dynamically like custom fan control. There's also the sysctl and config if you need bulk/one time changes. I wonder what FreeBSD's reason was to disable procfs (last time I checked it was disabled and not removed).

[some_canuck]

what about /etc/sysctl.conf? i definitely use that.

[jabl]

what about /etc/sysctl.conf? i definitely use that.

That file is used by the aforementioned sysctl(8) tool, which uses the procfs interface. So it'll continue working as before.

[drjohnnyfever]

Looking at Linux sysctl.c I notice: Added /proc support, Dec 1995 That's a while ago.

I guess FreeBSD does not agree with "Mike Gancarz: The UNIX Philosophy" ?

Using procfs for userland interaction makes much more sense to me. For example (programmatically) explore, monitor, and change specific values dynamically like custom fan control. There's also the sysctl and config if you need bulk/one time changes. I wonder what FreeBSD's reason was to disable procfs (last time I checked it was disabled and not removed).

I'm not asserting FreeBSD's approach is superior, I'm am however more used to it. I think the UNIX Philosophy argument in favor of procfs is pretty weak. Yes everything as a file makes a lot of sense but it can be taken too far. Procfs in FreeBSD and Linux as far as I'm aware were modeled after the Plan9 implementation and didn't come from UNIX per-se anyway. When Linux gets rid of ioctl and sockets I'm willing to entertain the "kernel data as a filesystem is the only true way" argument.

Yes FreeBSD still has optional procfs support, mostly for quick and dirty ports of software with Linux-isms and to support the Linux-compat procfs for running Linux binaries. Inside it's implemented with sysctl(2). "Native" tools like top, htop, ps etc all use sysctl directly. The main reason for deprecating it was that it was a lot of code that wasn't being used actively since sysctl has been more popular on FreeBSD for ages.