5 ms·

>The C library is itself a user space program, so the rule that a user space program has to go through the C library obviously isn't logical. And the GNU C libr

>The C library is itself a user space program, so the rule that a user space program has to go through the C library obviously isn't logical. And the GNU C library is an optional tool, not an official part of the kernel interface (if it were the latter, I would expect to see it packaged with the kernel). Ohh, if only we could make C the second class citizen. C brings with itself meaningless legacy from 1969 into modern systems, like you might think openat2 was created recently, but it's designed for PDP-7, because it's C and stuff was always done this way.

lelanthran 5y ago
What would be the first class citizen after you make C second class?
- GoblinSlayer 5y ago
  More precisely it's about making PDP-7 design the second class citizen. Interoperable design becomes the first class instead. POSIX would be implemented on top of that.
  - lelanthran 5y ago
    I understand that, but right now the C ABI is first class, and every language can call into it. What replacement are you proposing that every language can call into? How would a migration of existing Java, Python, Ruby, C++ etc programs be done to this new interface? Do programs need to be modified at the source level? Just recompiled? How will the existing programs that cannot be recompiled be handled? I quite aware that you can make the C ABI a shim into the new first class ABI to make existing programs work, but why would anyone target the new ABI when the existing one still works?
    - GoblinSlayer 5y ago
      Obviously it's not aimed at people who want to use only POSIX.
      - lelanthran 5y ago
        > Obviously it's not aimed at people who want to use only POSIX. Okay, then it's aimed at people who want to use more than just POSIX, right? That's the entire world. In which case the question still applies - how do you migrate everyone over to your new interoperable ABI? How will I run Gimp, Firefox/Thunderbird, IntelliJ, VSCode, Slack, Xterm, all my command-line tools (tar, grep, etc), Git, Meld, Starcraft 2 (and all 100+ games in my Steam library, and Steam itself) and more? How do you see your replacement running MySQL, Apache, Nginx, PostgreSQL, bash/zsh/etc, SQLite, stunnel, netcat, wireshark/tcpdump, etc? Do they all have to be recompiled? Replaced with new sootware? Because each and every one of the software I listed above depends on a C ABI. And any shim provided to make existing software work will simply result in developers ignoring your new ABI and targeting the C ABI for maximum compatibility.
matheusmoreira 5y ago
With Linux, you can! I started this project years ago just to prove to myself that it was possible. Every Linux process interfaces through the kernel via the system call interface. It is stable and language agnostic. The interface is defined at the processor architecture level. https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/syscalls https://github.com/torvalds/linux/blob/master/Documentation/... https://man7.org/linux/man-pages/man2/syscall.2.html https://man7.org/linux/man-pages/man2/syscall.2.html Any compiler can emit this sort of code, including JIT compilers! It's possible to discard the entire C user space and rewrite everything in Rust. Would be a monumental effort but still. Note that no matter what there will be at least one C library remaining: the vDSO the kernel maps into the address space of every process. https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/vdso https://github.com/torvalds/linux/blob/master/Documentation/...
- remram 5y ago
  Isn't this the route Golang famously went, with poor results? https://news.ycombinator.com/item?id=25997506 https://news.ycombinator.com/item?id=25997506 Apparently for BSD, the ABI is not that stable, glibc works around bugs on some platforms (adding memory barriers etc), and there are security features that check the origin of syscalls. I wonder whether this is truly acceptable on Linux...
  - matheusmoreira 5y ago
    It is my understanding that Go attempted to perform direct system calls on systems where it was never supported. As a result, Go programs stopped working when the binary interface changed. This is not a problem on Linux. > glibc works around bugs on some platforms (adding memory barriers etc) That's really interesting. Do you have examples of such fixes? I'm more familiar with musl sources, glibc proved to be somewhat difficult to navigate.
- lelanthran 5y ago
  > Any compiler can emit this sort of code, including JIT compilers! It's possible to discard the entire C user space and rewrite everything in Rust. Well, yeah, but that's a tautology, no? A willingness to discard everything indicates a willingness to rewrite everything. So, yeah, it is possible to rewrite everything if you are willing to rewrite everything.

lelanthran 5y ago

What would be the first class citizen after you make C second class?

GoblinSlayer 5y ago
More precisely it's about making PDP-7 design the second class citizen. Interoperable design becomes the first class instead. POSIX would be implemented on top of that.
- lelanthran 5y ago
  I understand that, but right now the C ABI is first class, and every language can call into it. What replacement are you proposing that every language can call into? How would a migration of existing Java, Python, Ruby, C++ etc programs be done to this new interface? Do programs need to be modified at the source level? Just recompiled? How will the existing programs that cannot be recompiled be handled? I quite aware that you can make the C ABI a shim into the new first class ABI to make existing programs work, but why would anyone target the new ABI when the existing one still works?
  - GoblinSlayer 5y ago
    Obviously it's not aimed at people who want to use only POSIX.
    - lelanthran 5y ago
      > Obviously it's not aimed at people who want to use only POSIX. Okay, then it's aimed at people who want to use more than just POSIX, right? That's the entire world. In which case the question still applies - how do you migrate everyone over to your new interoperable ABI? How will I run Gimp, Firefox/Thunderbird, IntelliJ, VSCode, Slack, Xterm, all my command-line tools (tar, grep, etc), Git, Meld, Starcraft 2 (and all 100+ games in my Steam library, and Steam itself) and more? How do you see your replacement running MySQL, Apache, Nginx, PostgreSQL, bash/zsh/etc, SQLite, stunnel, netcat, wireshark/tcpdump, etc? Do they all have to be recompiled? Replaced with new sootware? Because each and every one of the software I listed above depends on a C ABI. And any shim provided to make existing software work will simply result in developers ignoring your new ABI and targeting the C ABI for maximum compatibility.

matheusmoreira 5y ago

With Linux, you can! I started this project years ago just to prove to myself that it was possible. Every Linux process interfaces through the kernel via the system call interface. It is stable and language agnostic. The interface is defined at the processor architecture level. https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/syscalls https://github.com/torvalds/linux/blob/master/Documentation/... https://man7.org/linux/man-pages/man2/syscall.2.html https://man7.org/linux/man-pages/man2/syscall.2.html Any compiler can emit this sort of code, including JIT compilers! It's possible to discard the entire C user space and rewrite everything in Rust. Would be a monumental effort but still. Note that no matter what there will be at least one C library remaining: the vDSO the kernel maps into the address space of every process. https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/vdso https://github.com/torvalds/linux/blob/master/Documentation/...

remram 5y ago
Isn't this the route Golang famously went, with poor results? https://news.ycombinator.com/item?id=25997506 https://news.ycombinator.com/item?id=25997506 Apparently for BSD, the ABI is not that stable, glibc works around bugs on some platforms (adding memory barriers etc), and there are security features that check the origin of syscalls. I wonder whether this is truly acceptable on Linux...
- matheusmoreira 5y ago
  It is my understanding that Go attempted to perform direct system calls on systems where it was never supported. As a result, Go programs stopped working when the binary interface changed. This is not a problem on Linux. > glibc works around bugs on some platforms (adding memory barriers etc) That's really interesting. Do you have examples of such fixes? I'm more familiar with musl sources, glibc proved to be somewhat difficult to navigate.
lelanthran 5y ago
> Any compiler can emit this sort of code, including JIT compilers! It's possible to discard the entire C user space and rewrite everything in Rust. Well, yeah, but that's a tautology, no? A willingness to discard everything indicates a willingness to rewrite everything. So, yeah, it is possible to rewrite everything if you are willing to rewrite everything.