You might need that when you want to reimplement Linux, the Joyent team did that on their OS (derived from solaris) so that user can run linux binaries on a solaris kernel (so thay have dtrace, zfs, mdb, ...) Bryan Cantrill did a bunch of conferences on that (one here: https://youtu.be/TrfD3pC0VSs)
The idea behind is that Linux is only a list of syscalls, if you are able to reimplement them, you reimplement linux, you don't need anything else. On the contrary if you want to reimplement a BSD you need to reimplement their libc (and perhaps some other libraries)
I'm not ultra familiar with the topic so if someone wants to correct me please do but :
- Linux has always been described as just a kernel, which translates as just a syscall table. The fact that this table is stable or not is not relevant here.
- *BSD on the other hand are shipping a kernel plus a lot of libraries/binaries, if you want to simulate a BSD system, you have to expose those libraries/binaries.
It's not so much a technical difference, it's more of a different approach to OS development (kernel space vs kernel/user space).
Thing is, if syscalls in BSD are considered stable the way they are in Linux, then you could just ship your own kernel with BSD's libc. But if they consider it an internal API between kernel and libc, and apps are only ever supposed to depend on libc, then of course that doesn't work.
So stability of syscall API is the de facto differentiating factor here. It sounds like Microsoft couldn't do "Windows Subsystem for BSD" the way it did WSL, for example.
I had cause to consult a syscall table (not this one, a correct one, forget where I found it) when doing something or other with fasm. fasm's macros are pretty dang advanced...I remember having argument length checking and rudimentary type checking as well. Then I got done yak shaving and remembered that programming in asm sucks.
But yeah, it's for writing your own syscall wrappers. Something not exported by libc, or more likely if you're not using libc.
Sometimes, yes, you'll need to write your own syscall wrappers. For example, there isn't a gettid (get thread ID) function in Glibc, but you can work around this by calling the syscall directly.
The other case where this is useful is if you're wanting to write userspace assembly without calling a C library. This may be especially useful when you're writing a compiler, or if you're trying to write small shellcodes for some reason.
Or to try making more sense of some libc implementation. The syscall stuff in glibc and musl both have a good bit of preprocessor voodoo to make syscalls feel more like function calls.
The idea behind is that Linux is only a list of syscalls, if you are able to reimplement them, you reimplement linux, you don't need anything else. On the contrary if you want to reimplement a BSD you need to reimplement their libc (and perhaps some other libraries)