3 ms·

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

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
    I agree with you completely. And a bigger annoyance than generating headers is actually reading them; C is really not a pleasant format to parse.
twic 3y ago
Did Redox literally have to write their own libc? With the exact libc symbols and semantics? If so, that is a bit of a shame. But the solution is to introduce an abstraction layer on top of libc in the stdlib, so there could be a Redox implementation that doesn't have to imitate libc.
- steveklabnik 3y ago
  > But the solution is to introduce an abstraction layer on top of libc in the stdlib Which stdlib? Redox isn't trying to only run Rust programs.

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
  I agree with you completely. And a bigger annoyance than generating headers is actually reading them; C is really not a pleasant format to parse.

twic 3y ago

Did Redox literally have to write their own libc? With the exact libc symbols and semantics? If so, that is a bit of a shame. But the solution is to introduce an abstraction layer on top of libc in the stdlib, so there could be a Redox implementation that doesn't have to imitate libc.

steveklabnik 3y ago
> But the solution is to introduce an abstraction layer on top of libc in the stdlib Which stdlib? Redox isn't trying to only run Rust programs.