3 ms·

You can't write code that expects to call C functions to interop with the Linux system interface. You have to call the syscalls directly without a C-like ABI.

You can't write code that expects to call C functions to interop with the Linux system interface. You have to call the syscalls directly without a C-like ABI. There is some functionality you can access from glibc at link time, but not all of it (as some are implemented as macros). Even then, that's glibc providing the interface, not Linux. As the other commenter said, this is subtle (and probably non-consequential) for most people, but if you are writing an abstraction over the system interfaces, it becomes very significant to your codebase. As an example, you can lookup how Go does syscalls on Linux. It has some important consequences for their low-level design decisions: https://utcc.utoronto.ca/~cks/space/blog/programming/GoSchedulerAndSyscalls https://utcc.utoronto.ca/~cks/space/blog/programming/GoSched...

wahern 6y ago
OTOH, Linux's setuid and similar interfaces are per-thread, not per-process as required by POSIX and as what most people would expect--particularly in the context of software security. glibc and musl have to emulate the POSIX behavior, and doing it correctly is extremely tricky. See https://ewontfix.com/17/ https://ewontfix.com/17/ Linux's various APIs used for container frameworks also tend to be per-thread, not per-process; that can be both useful and a giant headache, depending on context. It's somewhat ironic that Go was used for Docker as Go is pretty much the worst possible language you could choose in this regard. Go deliberately and thoroughly obscures native thread and process semantics. IIRC, Docker was already well along and established before Go even introduced an API for pinning a goroutine to a machine (kernel) thread. I once ran across a comment where the author of (I think) runc lamented his choice of Go. But I haven't been able to find it again, so it's entirely possible it's a misattribution on my part.

wahern 6y ago

OTOH, Linux's setuid and similar interfaces are per-thread, not per-process as required by POSIX and as what most people would expect--particularly in the context of software security. glibc and musl have to emulate the POSIX behavior, and doing it correctly is extremely tricky. See https://ewontfix.com/17/ https://ewontfix.com/17/ Linux's various APIs used for container frameworks also tend to be per-thread, not per-process; that can be both useful and a giant headache, depending on context. It's somewhat ironic that Go was used for Docker as Go is pretty much the worst possible language you could choose in this regard. Go deliberately and thoroughly obscures native thread and process semantics. IIRC, Docker was already well along and established before Go even introduced an API for pinning a goroutine to a machine (kernel) thread. I once ran across a comment where the author of (I think) runc lamented his choice of Go. But I haven't been able to find it again, so it's entirely possible it's a misattribution on my part.