Announcement

Collapse
No announcement yet.

Linux 5.5 Finally Doing Away With The SYSCTL System Call

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.5 Finally Doing Away With The SYSCTL System Call

    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?pag...SYSCTL-SYSCALL

  • #2
    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

    Comment


    • #3
      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 ?

      Comment


      • #4
        Note that this refers to the sysctl(2) system call, which should not be configured in your kernel, and is not wrapped by glibc. The sysctl(8) command does not use it, but requires procfs. ie. Unless you are a very odd duck, this should not affect you.

        Comment


        • #5
          Originally posted by gsedej View Post
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              Originally posted by coder View Post
              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.

              Comment


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

                Originally posted by drjohnnyfever View Post
                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).

                Comment


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

                  Comment


                  • #10
                    Originally posted by some_canuck View Post
                    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.

                    Comment

                    Working...
                    X