Hacker News Reader

Comment by masklinn | Hacker News Reader

> At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years

IIRC raw syscalls are an officially supported kernel API, that's why you can have alternate libc implementations (e.g. musl), and Linux is an oddity in that, on most systems even if the syscalls are fairly stable there are no actual guarantees with respect to them, and the only officially supported interface to the kernel is the standard library. OSX does not allow statically linking libSystem for that reason for instance.

View on HN

     IIRC raw syscalls are an officially supported kernel API

The term you are looking for is We don't break userland. Once a systemcall goes live it is engraved in stone. This is why if you look though the syscall table you see call, call2, call_ext.

You're implying that exposing syscalls as the ABI instead of a higher level ABI is the only way to get backwards compatibility but that's not true. OS X can change its syscalls without breaking userland in exactly the way GP says: don't allow static linking of e.g. libSystem and its ABI is the ABI you're expected to use instead of directly calling syscalls.

Sure, Linux makes promises about its syscalls. But that's not the only way to get robust backwards compatibility and as GP says it's the oddity in that respect.

golang also targets syscalls instead of the C standard library (or other libraries except for windows, and maybe others), which is interesting on e.g., Darwin:

https://github.com/golang/go/issues/17490

Yeah the linked issue (16570) is the most interesting one, with the Go runtime breaking multiple times in the runup to Sierra as Apple changed the ABI of the underlying gettimeofday syscall.

Wow, that seems like a really bad approach for Go to take. So is anybody actually using Go on OS X? I guess maybe not, if all the real Go deployments are on servers running Linux.

I do a bunch of development work using Go on OSX but I do deploy the resulting solutions on Linux.

Aha, that's kind of what I'd figured. Work on Mac, deploy on Linux.

It makes me think twice about e.g. using Go as part of the build workflow in a big project if it's going to randomly stop working on various OS X versions.

>"golang also targets syscalls instead of the C standard library"

What would have been the reasons for targeting syscalls directly instead of the C standard library?

> What would have been the reasons for targeting syscalls directly instead of the C standard library?

Since the standard library probably assumes (and requires) a C stack, linking against the standard library would require cgo (or some other specific workaround) on non-linux platforms.

I'm guessing it has to do with the fact that you can build go binaries not linked with libc, they also expose syscall.RawSyscall anyway that all the other syscall wrappers call out to last time I looked

Interesting, thanks for linking that.

Another example: for OpenBSD part of the manual upgrade procedure (not the recommended method, but useful if you don't have a console to run the installer) is to make a copy of /sbin/reboot, because there's a good chance that the new /sbin/reboot you're about to install will have the wrong syscalls for the running kernel.

Reply on news.ycombinator.com