Announcement

Collapse
No announcement yet.

Linux READFILE System Call Revived Now That It Might Have A User

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

  • Linux READFILE System Call Revived Now That It Might Have A User

    Phoronix: Linux READFILE System Call Revived Now That It Might Have A User

    Earlier this year we mentioned Greg Kroah-Hartman working on a new READFILE system call. The goal of this new syscall is for reading small and medium files more efficiently by having one call to read a file straight into a buffer without having to use the separate open/read/close system calls. It's looking like that system call is back on the table and could be mainlined now that there's a possible user...

    http://www.phoronix.com/scan.php?pag...yscall-Revived

  • #2
    But if you accidentally read a file that is larger than your RAM then it is going to blow up your computer. 💥

    Comment


    • #3
      Waiting for a solid reason? Aren't the speed and ease of use solid reasons enough? Why wouldn't everyone (who's not dealing with huge files) use this call?

      Comment


      • #4
        Originally posted by M1kkko View Post
        Waiting for a solid reason? Aren't the speed and ease of use solid reasons enough? Why wouldn't everyone (who's not dealing with huge files) use this call?
        The performance differences may not be significant outside of synthetic benchmarks, portability concerns, not wanting to depend on the latest kernel, glibc etc. There is also the general notion that if you don't have outside consumers expressing interest, you may not get the feedback, validation required to perhaps refine the API before the ABI becomes something you have to maintain forever.

        Comment


        • #5
          As the patch is tiny, it's a very nice example how in practise new syscalls are added.

          Comment


          • #6
            Originally posted by M1kkko View Post
            Waiting for a solid reason? Aren't the speed and ease of use solid reasons enough? Why wouldn't everyone (who's not dealing with huge files) use this call?
            When reading normal (non-sysfs/procfs) files, the program usually needs to call stat(path) or fstat(fd) in order to allocate a buffer of an appropriate size (stat.st_size field). When using open-read-close the program can use fstat(fd), but when using readfile() the program is more likely to use stat(path). stat(path) is slower than fstat(fd).

            Comment


            • #7
              Originally posted by uid313 View Post
              But if you accidentally read a file that is larger than your RAM then it is going to blow up your computer. 💥
              But until you realize this will have a read limit of course to prevent this kind of problems.

              Comment


              • #8
                So they need a new non-portable "filesystem" call to hack around performance issues related to a VIRTUAL filesystem sysfs? Sounds like scary shit, poor design and bad practises. I know the UNIX philosophy is about exposing all kinds of stuff as "files", but if it leads to last-resort hacks like this on the other side, then what the hell is the point?

                Comment


                • #9
                  Originally posted by uid313 View Post
                  But if you accidentally read a file that is larger than your RAM then it is going to blow up your computer. 💥
                  It doesn't because in each call you specify how many bytes should be read at most (MAX) and it returns how many bytes it actually read (result <= MAX).

                  I just don't like that instead of returning the possible error in the return value (ssize_t) they use errno for this, I know that it's thread safe and a tradition but I just don't like that you have to access another variable for this and for errno to become thread safe posix had to redefine its meaning. It's just more compact to use one var for 2 purposes since it's signed and can hold both values (not at the same time obviously - it's not needed).

                  Comment


                  • #10
                    Originally posted by cl333r View Post

                    It doesn't because in each call you specify how many bytes should be read at most (MAX) and it returns how many bytes it actually read (result <= MAX).

                    I just don't like that instead of returning the possible error in the return value (ssize_t) they use errno for this, I know that it's thread safe and a tradition but I just don't like that you have to access another variable for this and for errno to become thread safe posix had to redefine its meaning. It's just more compact to use one var for 2 purposes since it's signed and can hold both values (not at the same time obviously - it's not needed).
                    Rust handles that really nicely with the Result<T> enum type.

                    So then you get the result and check if its Ok() or Err(), if its Ok() then you unwrap it and get the data.

                    Comment

                    Working...
                    X