Announcement

Collapse
No announcement yet.

Kernel Developers Debate Having An Official Linux System Wrapper Library

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

  • Kernel Developers Debate Having An Official Linux System Wrapper Library

    Phoronix: Kernel Developers Debate Having An Official Linux System Wrapper Library

    As new system calls get added to the Linux kernel, these syscalls generally get added to Glibc (and other libc libraries) for developers to make easy use of them from their applications. But as Glibc doesn't provide 1:1 coverage of system calls, sometimes is delayed in their support for new calls, and other factors, there is a discussion about providing an official Linux system wrapper library that could potentially live as part of the kernel source tree...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Couldn't systemd fill this gap ?

    Comment


    • #3
      Originally posted by Candy View Post
      Couldn't systemd fill this gap ?
      Nice bait. I'll fetch my popcorn now

      Comment


      • #4
        Why a library? I would have expected a header file, which has needed inline functions with asm syscall, e.g.

        static inline long sys_write(unsigned int fd, const char *ptr, unsigned long size)
        {
        long x;
        __asm__ volatile ("syscall" : "=a"(x) : "a"(__NR_write), "D"(fd), "S"(ptr), "d"(size) : "%rcx", "%r11");
        return x;
        }

        Comment


        • #5
          Originally posted by cfeck View Post
          Why a library? I would have expected a header file, which has needed inline functions with asm syscall, e.g.

          static inline long sys_write(unsigned int fd, const char *ptr, unsigned long size)
          {
          long x;
          __asm__ volatile ("syscall" : "=a"(x) : "a"(__NR_write), "D"(fd), "S"(ptr), "d"(size) : "%rcx", "%r11");
          return x;
          }
          Because you probably don't want to inline every single call to eg. write() (not always, anyways. The option to do so would be nice to have though). At the very least, with your proposed approach you could potentially end up with a copy of each syscall wrapper in each translation unit, which may or may not be "the right thing to do".

          Comment


          • #6
            It almost feels like after 30 years they finally start to realize the importance of a standard API. Almost.

            Comment


            • #7
              Originally posted by Candy View Post
              Couldn't systemd fill this gap ?
              it could, but if systemd did it, that would be losing focus on its goal which is to make their own kernel

              Comment


              • #8
                Yes please! Linux absolutely sucks in this regard compared to windows. On windows we get a rich selection of system APIs to do just about anything. On linux every app parses text from sysfs. Same stupid thing implemented over and over and over... sysfs is awesome for shellscripting, not so much for actual c/++ programs.

                Comment


                • #9
                  Originally posted by anarki2 View Post
                  It almost feels like after 30 years they finally start to realize the importance of a standard API. Almost.
                  Two thoughts:

                  - Better late than never
                  - hallelujah!!!

                  Comment


                  • #10
                    I'm very much in favor of this. There are several cases in my projects where I've had to use the syscall() function because glibc or Android's bionic didn't have a wrapper for a syscall. This would also help projects/languages that don't link against libc at all, like golang (without cgo).

                    Comment

                    Working...
                    X