3 ms·

When it comes to linking against the kernel, it is worth remembering that of the major operating systems, there is but one where the stable kernel interface is

When it comes to linking against the kernel, it is worth remembering that of the major operating systems, there is but one where the stable kernel interface is the syscalls directly--Linux. If you use Windows, the stable interface is linking against kernel32. If you use Darwin or the BSDs, your stable interface is libc (and for some of them, there's no stable ABI, only a stable C API). Note that Go has given up trying to avoid using libc on these systems, which should be a sign of how fantastical the idea of a pure, non-C system is for the foreseeable future.

titzer 3y ago
It's really unfortunate. I've crowed about this before. The syscall interface on Darwin is so close to being stable. Even though it's not officially supported (TM), the UNIX syscalls basically don't change. (Only one needless breaking change that I recall in the past 10 years on x86). We need to shake the C demon and the only way is to push back on kernel ABIs changing. Virgil doesn't depend on C and runs happily on Linux and Darwin. And yea, I know, MacOS breaks.
- eptcyka 3y ago
  IOCTLs have been broken between major versions before. And by broken, a field has been added to a struct.
  - einpoklum 3y ago
    And?... If the IOCTLs are different, then you compile a different binary. What's the big deal? Rust is a compiled language after all.
- eqvinox 3y ago
  There is no C demon. The OS ABI is (de facto — please spare the de jure nitpickery) a bunch of symbols you can call and a calling convention for them. You call into that ABI. What language is used to implement the other side of that ABI is irrelevant. The fact that this ABI is called "libc" doesn't really mean a whole lot. Neither is the fact that the same library contains a whole bunch of functions primarily useful to programs written in C.
  - 10000truths 3y ago
    Libc isn't just an ABI, it's a library - one that relies on an opinionated runtime. That's the demon, it's incidental complexity that has been ossified by past design decisions. There is no fundamental reason that interacting with an OS has to require anything more than the minimum necessary to transfer data to/from the kernel (e.g. supervisor trap instruction).
eqvinox 3y ago
ACK, calling libc is a feature, not a bug. I don't understand this obsession with trying to make direct syscalls for everything. The Redox example ("The Redox project had to write their own libc, in Rust, in order to solve that chicken and egg problem.") is pretty weird too — you're writing your own OS, how is this a chicken and egg problem? My expectation would've been to write a custom "std" regardless? There's some misunderstanding buried there somewhere…
- stefncb 3y ago
  You don't need stable syscalls. Instead of exposing libc as a dynamic library with a questionable ABI, make a stable ABI and expose interface files that contain function names and parameters. You can easily parse these files and generate code for any language to interface with the system. You can do this with syscalls, you can do this with dynamic libraries, or you can do it with IPC. The point is that it's completely language agnostic and not a pain to parse and use.
  - jcranmer 3y ago
    The stable ABI for all the major OSes at this point is expressed in C, or put another way, C is the language of FFIs at the moment. This is not something I am happy with, and I wish we could start moving away from it, but the result is that the way you describe the ABI of your OS right now is to provide a C header file containing function prototypes and structure definitions. In principle, it's also worth pointing out that libc is really three separate (conceptual) things. There's libsyscall, which is the bare wrapper around system calls; there's libuss, OS services provided entirely in userspace and not the kernel (dynamic linking and some aspects of threading come to mind here); and finally, libcrt, which is the actual C runtime that implements the C standard library (e.g., fopen). It's really unfortunate that on most OSes, all of these are combined into one library called libc, although Windows actually separates these into different libraries (ntdll, which is not stable; kernel32-ish, which is stable; and msvcrt, which you have historically had to ship yourself!).
    - stefncb 3y ago
baq 3y ago
Note winapi is the only widely adopted stable cross-platform api. They’ve clearly done something right. It took a while to implement it on non-Windows oses, but that reality is now here: if you want to run an executable on basically any modern OS and hardware, use the win64 build.

titzer 3y ago

It's really unfortunate. I've crowed about this before. The syscall interface on Darwin is so close to being stable. Even though it's not officially supported (TM), the UNIX syscalls basically don't change. (Only one needless breaking change that I recall in the past 10 years on x86). We need to shake the C demon and the only way is to push back on kernel ABIs changing. Virgil doesn't depend on C and runs happily on Linux and Darwin. And yea, I know, MacOS breaks.

eptcyka 3y ago
IOCTLs have been broken between major versions before. And by broken, a field has been added to a struct.
- einpoklum 3y ago
  And?... If the IOCTLs are different, then you compile a different binary. What's the big deal? Rust is a compiled language after all.
eqvinox 3y ago
There is no C demon. The OS ABI is (de facto — please spare the de jure nitpickery) a bunch of symbols you can call and a calling convention for them. You call into that ABI. What language is used to implement the other side of that ABI is irrelevant. The fact that this ABI is called "libc" doesn't really mean a whole lot. Neither is the fact that the same library contains a whole bunch of functions primarily useful to programs written in C.
- 10000truths 3y ago
  Libc isn't just an ABI, it's a library - one that relies on an opinionated runtime. That's the demon, it's incidental complexity that has been ossified by past design decisions. There is no fundamental reason that interacting with an OS has to require anything more than the minimum necessary to transfer data to/from the kernel (e.g. supervisor trap instruction).

eqvinox 3y ago

ACK, calling libc is a feature, not a bug. I don't understand this obsession with trying to make direct syscalls for everything. The Redox example ("The Redox project had to write their own libc, in Rust, in order to solve that chicken and egg problem.") is pretty weird too — you're writing your own OS, how is this a chicken and egg problem? My expectation would've been to write a custom "std" regardless? There's some misunderstanding buried there somewhere…

stefncb 3y ago
You don't need stable syscalls. Instead of exposing libc as a dynamic library with a questionable ABI, make a stable ABI and expose interface files that contain function names and parameters. You can easily parse these files and generate code for any language to interface with the system. You can do this with syscalls, you can do this with dynamic libraries, or you can do it with IPC. The point is that it's completely language agnostic and not a pain to parse and use.
- jcranmer 3y ago
  The stable ABI for all the major OSes at this point is expressed in C, or put another way, C is the language of FFIs at the moment. This is not something I am happy with, and I wish we could start moving away from it, but the result is that the way you describe the ABI of your OS right now is to provide a C header file containing function prototypes and structure definitions. In principle, it's also worth pointing out that libc is really three separate (conceptual) things. There's libsyscall, which is the bare wrapper around system calls; there's libuss, OS services provided entirely in userspace and not the kernel (dynamic linking and some aspects of threading come to mind here); and finally, libcrt, which is the actual C runtime that implements the C standard library (e.g., fopen). It's really unfortunate that on most OSes, all of these are combined into one library called libc, although Windows actually separates these into different libraries (ntdll, which is not stable; kernel32-ish, which is stable; and msvcrt, which you have historically had to ship yourself!).
  - stefncb 3y ago

baq 3y ago

Note winapi is the only widely adopted stable cross-platform api. They’ve clearly done something right. It took a while to implement it on non-Windows oses, but that reality is now here: if you want to run an executable on basically any modern OS and hardware, use the win64 build.