Linux Syscall Support

See also Linux&#x27;s nolibc headers, which allows one to write C software that completely bypass libc, but instead directly operate through syscalls.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;tree&#x2F;master&#x2F;tools&#x2F;include&#x2F;nolibc">https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;tree&#x2F;master&#x2F;tools&#x2F;include&#x2F;...</a><p>A sample use-case? I was developing an Erlang-like actor platform that should operate under Linux as well as a bare-metal microkernel, and all I needed is a light layer over syscalls instead of pulling the entire glibc. Also it provides a simple implementation for standard C functions (memcpy, printf) so I don&#x27;t have to write them myself.

Can&#x27;t wait for Zig team to adopt this over libc, citing concerns about &quot;libc not existing on certain configurations&quot;[1]<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;issues&#x2F;1840">https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;issues&#x2F;1840</a>

Disappointing that errors are still signaled by assigning to `errno` (you can apparently override this to some other global, but it has to be a global or global-like lvalue).<p>The kernel actually signals errors by returning a negative error code (on most arches), which seems like a better calling convention. Storing errors in something like `errno` opens a whole can of worms around thread safety and signal safety, while seemingly providing very little benefit beyond following tradition.

&gt; We try to hide some of the differences between arches when reasonably feasible. e.g. Newer architectures no longer provide an open syscall, but do provide openat. We will still expose a sys_open helper by default that calls into openat instead.<p>Sometimes you actually want to make sure that the exact syscall is called; e.g. you&#x27;re writing a little program protected by strict seccomp rules. If the layer can magically call some other syscall under the hood this won&#x27;t work anymore.

You have to be pretty careful when using syscalls directly, at least in the presence of some libc. For example, from what I have gathered from random tidbits here and there, it&#x27;s not a good idea to use any of the fork-like calls (fork, clone, etc.) if you have any threads that were created using glibc.

I&#x27;ve been using my own version of this. Maybe I&#x27;ll switch over, this looks more complete.

Using go is a nice way to do that by default as it also directly uses syscalls (see the <i>sys</i> package)

Just a friendly reminder that syscall() is a vararg function. Meaning, you can&#x27;t just go throwing arguments at it (so maybe it&#x27;s better to use this wrapper to avoid problems instead).<p>For example, on a 64-bit arch, this code would be sus.<p>syscall(__NR_syscall_taking_6_args, 1, 2, 3, 4, 5, 6);<p>Quiz: why<p>PS: it&#x27;s a common mistake, so I thought I&#x27;d save you a trip down the debugging rabbit hole.

0-Day incoming

So web apps can make Linux sys calls? Or its about Chrome OS?