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