Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux System Call Table

thevivekpandey.github.io

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Linux System Call Table

#41

Post by RJIb8RBYxzAMX9u »

zzzcpan wrote: post #29
legulere wrote: post #10

Earlier quoted context omitted.

System calls have not stability guarantee on macOS. You should use libc instead. In general the use of syscalls directly is fairly limited. Edit: for instance go broke once for macOS Sierra, when Apple changed the gettimeofday system call: https://github.com/golang/go/issues/16570

Linux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.

I think you're confusing driver APIs and syscalls. Both are infamous for their respective lack of, or guarantee of stability.

Re: Linux System Call Table

#42

Post by caf »

wahern wrote: post #33
zzzcpan wrote: post #29

Earlier quoted context omitted.

Linux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.

Yes it does, at least in the sense that syscalls which become officially public will never be removed from Linus' tree except in rare circumstances (i.e. proof that nobody is using it), nor will the arguments change. This is Linus' famous "never break user space" ABI mantra. While distributions may deprecate and remove them (e.g. sysctl(2)) they certainly won't be assigned new IDs. A table won't help in such cases.

Exactly. This is why, for example, the original 'mmap' system call entry point on x86 still exists, even though it is overwhelmingly likely that every program on your machine is actually going to use the 'mmap2' entry point.

Re: Linux System Call Table

#44

Post by xelxebar »

throwaway613834 wrote: post #11

What is the use case for this? Is it for someone trying to write their own syscall wrappers?

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.

Re: Linux System Call Table

#46

Post by ajross »

yjftsjthsd-h wrote: post #36
Manozco wrote: post #20

Earlier quoted context omitted.

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, y…

For that matter, this is how Widows's Linux compatibility layer works.

FreeBSD had a linux syscall layer before either of those, I believe.

Re: Linux System Call Table

#47

Post by voltagex_ »

akrasuski1 wrote: post #18

Actually, the syscall numbers are wrong! This reference seems better: http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x... Consider simple C program: #define _GNU_SOURCE #include int main(){ syscall(276); } Strace'ing it shows the syscall used is tee, just as the reference I linked shows, and not pwritev as in OP's table.

It's odd. The owner of this Git repo has Issues turned off so I can't post a question/issue, and it appears to have been auto-generated - https://github.com/thevivekpandey/syscalls-table-64bit is a "fork" of https://github.com/paolostivanin/syscalls-table-64bit

Re: Linux System Call Table

#49

Post by int_19h »

Manozco wrote: post #20
throwaway613834 wrote: post #11

What is the use case for this? Is it for someone trying to write their own syscall wrappers?

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, y…

> On the contrary if you want to reimplement a BSD you need to reimplement their libc (and perhaps some other libraries)

To clarify, what you're saying is that in BSD land, the syscall API is not considered stable, but libc is?

Re: Linux System Call Table

#50

Post by dungle6 »

zzzcpan wrote: post #29
legulere wrote: post #10

Earlier quoted context omitted.

System calls have not stability guarantee on macOS. You should use libc instead. In general the use of syscalls directly is fairly limited. Edit: for instance go broke once for macOS Sierra, when Apple changed the gettimeofday system call: https://github.com/golang/go/issues/16570

Linux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.

Your first sentence is absolutely false. The syscall table is the stable API of the linux kernel.
Post reply on HN