Announcement

Collapse
No announcement yet.

Linux 5.9 Set To Bring "Close_Range" System Call - Coordinated With FreeBSD Developers

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

  • Linux 5.9 Set To Bring "Close_Range" System Call - Coordinated With FreeBSD Developers

    Phoronix: Linux 5.9 Set To Bring "Close_Range" System Call - Coordinated With FreeBSD Developers

    The close_range() system call is intended to allow efficiently closing a range of file descriptors (or all file descriptors) of the calling task. This system call was devised in cooperation with FreeBSD developers...

    http://www.phoronix.com/scan.php?pag....9-Close-Range

  • #2
    Very interesting to me.

    Comment


    • #3
      The article isn't too clear about origin:

      This is coordinated with the FreeBSD folks which have copied our version of
      this syscall and in the meantime have already merged it in April 2019:
      https://reviews.freebsd.org/D21627
      https://svnweb.freebsd.org/base?view...evision=359836

      Comment


      • #4
        inb4 people claiming that parsing ascii stuff from /proc on a loop is better than a dedicated system call, and that this is bloating the kernel.

        Comment


        • #5
          Originally posted by starshipeleven View Post
          inb4 people claiming that parsing ascii stuff from /proc on a loop is better than a dedicated system call, and that this is bloating the kernel.
          I don't think anyone claims that munging text files is better than a system call.

          Arguably I would go one step further and state that /proc is "never" a good idea and shouldn't even exist

          Comment


          • #6
            Bleh. An older version of dpkg had a loop like

            Code:
            for (int i = 0; i < sysconf(_SC_OPEN_MAX); i++) {
                close(i);
            }
            which ran before each exec() to avoid leaking files to child processes. They were using O_CLOEXEC, but thought it would be a good idea to do this just in case they missed one. And yes, sysconf() got called in the loop there.

            I had that version of dpkg on Raspbian and it was horrendously slow. I'd rather have a way to say "mark each file I'm going to open from now on as O_CLOEXEC" (of course, that may or may not play well with other people's code) or some new posix_spawn() flag instead of this mess of closing random fds just in case.
            Last edited by GrayShade; 08-04-2020, 02:05 PM.

            Comment


            • #7
              Originally posted by kpedersen View Post

              I don't think anyone claims that munging text files is better than a system call.
              Well, someone did in the thread about the kernel call about mounted status https://www.phoronix.com/forums/foru...e-linux-kernel

              Arguably I would go one step further and state that /proc is "never" a good idea and shouldn't even exist
              Proc and Sys and whatever exist for shell scripts so admins can cobble together quick hacks to save the day, or for simple and basic embedded device use, and they are fine for that.

              If you are using them with an actual program in an actual programming language you are bad and should feel bad.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                If you are using them with an actual program in an actual programming language you are bad and should feel bad.
                A lot of tools _have_ to use procfs and sysfs because there are no native APIs available...

                But that is the unix way, not providing something that other OSs have provided for over 2-3 decades because it's based on ideas from over 4 decades ago.

                Comment


                • #9
                  Originally posted by xnor View Post
                  A lot of tools _have_ to use procfs and sysfs because there are no native APIs available...
                  Because noone is vehemently demanding for it and/or contributing it. Linux is adding stuff all the time, there is no religious cult that steals your kittens.

                  But that is the unix way, not providing something that other OSs have provided for over 2-3 decades because it's based on ideas from over 4 decades ago.
                  It's more like the opensource way, unless someone contributes something it probably won't be done by the current maintainers out of thin air and for free.

                  Comment


                  • #10
                    Originally posted by kpedersen View Post

                    I don't think anyone claims that munging text files is better than a system call.

                    Arguably I would go one step further and state that /proc is "never" a good idea and shouldn't even exist
                    Text isn't that much slower than binary and it is a heck of a lot easier to keep compatibility and to use it from scripts.

                    Have you ever had to write netlink code? Without an existing library? I have. Because we wanted a library written in native Go code. It was a pretty horrific experience. The connection tracking devs should probably be given a good talking to about writing documentation instead of saying "Use the library." Which is also lacking in documentation.

                    Comment

                    Working...
                    X