Hacker News Reader

Comment by jcranmer | Hacker News Reader

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.

View on HN

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…

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.

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!).

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.

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.

> 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.

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.

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.

IOCTLs have been broken between major versions before. And by broken, a field has been added to a struct.

And?...

If the IOCTLs are different, then you compile a different binary. What's the big deal? Rust is a compiled language after all.

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.

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).

Reply on news.ycombinator.com