7 ms·

I’m sure it would give people discomfort, but I wonder how it would work if the kernel presented a pseudo file system with an “include” and a “src” directory to

by jws 8y ago

I’m sure it would give people discomfort, but I wonder how it would work if the kernel presented a pseudo file system with an “include” and a “src” directory to provide C interfaces to the unassimilated syscalls. Just enough syntax to keep people from defining their own types and have to use the syscall() interface. Maybe make it a module so space constrained systems can leave it out. The kernel patch process could keep everything nicely in sync and native build processes would easily find the right source code. Cross compiling would require you to find and copies though.

tacostakohashi 8y ago
One issue with that idea is that the source code for implementing a system call is necessarily compiler-specific, it is not standard C. So, the issue would become which compiler (version) should the source code of the include/ and src/ be for? GCC? Clang?
- olliej 8y ago
  A lot of the problems occur in things like struct layout of syscall arguments, which would be cross platform. But then you run into the problem of how willing to commit to ABI stability in a non-posix API. I assume there’s some commitment to such at the moment, but how much also depends on *libc abstracting them? Libcs always seem to (to me) be approximately kernel version specific
  - Aic1kuir 8y ago
    Ancient glibc versions run ok on current kernels, you're just missing out on some newer features. Otherwise statically linked binaries would cease to work.
    - zaarn 8y ago
      There is still a limit, very old software doesn't run anymore, largely because something in the kernel broke it. But it has been years and nobody complained so nobody will revert this or fix it. Linus has stated as such and I think a few other maintainers agree there. If you don't find the problem until years later, chances are, too few people care.
deleted 8y ago
[deleted]
kayamon 8y ago
It actually already has this (kinda) -- the VDSO shared library. Although they only tend to implement a couple of syscalls in there. http://man7.org/linux/man-pages/man7/vdso.7.html http://man7.org/linux/man-pages/man7/vdso.7.html
- klodolph 8y ago
  VDSO does not have syscalls in it, that's actually the entire reason it exists… so you can communicate between the kernel and userspace without syscalls.

by jws 8y ago

tacostakohashi 8y ago

One issue with that idea is that the source code for implementing a system call is necessarily compiler-specific, it is not standard C. So, the issue would become which compiler (version) should the source code of the include/ and src/ be for? GCC? Clang?

olliej 8y ago
A lot of the problems occur in things like struct layout of syscall arguments, which would be cross platform. But then you run into the problem of how willing to commit to ABI stability in a non-posix API. I assume there’s some commitment to such at the moment, but how much also depends on *libc abstracting them? Libcs always seem to (to me) be approximately kernel version specific
- Aic1kuir 8y ago
  Ancient glibc versions run ok on current kernels, you're just missing out on some newer features. Otherwise statically linked binaries would cease to work.
  - zaarn 8y ago
    There is still a limit, very old software doesn't run anymore, largely because something in the kernel broke it. But it has been years and nobody complained so nobody will revert this or fix it. Linus has stated as such and I think a few other maintainers agree there. If you don't find the problem until years later, chances are, too few people care.

deleted 8y ago

[deleted]

kayamon 8y ago

It actually already has this (kinda) -- the VDSO shared library. Although they only tend to implement a couple of syscalls in there. http://man7.org/linux/man-pages/man7/vdso.7.html http://man7.org/linux/man-pages/man7/vdso.7.html

klodolph 8y ago
VDSO does not have syscalls in it, that's actually the entire reason it exists… so you can communicate between the kernel and userspace without syscalls.