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

51–60 of 65 posts

Re: Linux System Call Table

#51

Post by dungle6 »

guhcampos wrote: post #45

The mere fact that we are debating over the correctness of this table confirms the quality of the documentation of the OS we base our entire civilization upon is pretty poor.

Not really. Any idiot on the internet can put a poorly made piece of documentation for anything, as has been done here. The topic kernel development is also technically involved and frankly a very small minority of the tech world is intimately familiar with it (let alone in a position to make good use of the documentation), so it's not terribly surprising that there is some discussion over it.

Re: Linux System Call Table

#52

Post by int_19h »

legulere wrote: post #10
eatonphil wrote: post #4

This is great! It would be even more useful to have this for Mac OSX too. A lot of the projects I do ends up being on both Mac and Linux. It's always a pain to find the corresponding number for the system call on Mac.

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

Looking at this bug, it seems that Go has "fixed" it by fixing the syscall arguments, not by switching to libc.

Did they switch to libc since then?

If not, and given that Go apps are normally statically linked, does this mean that any precompiled Go app basically has a time bomb, in a sense that it'll break next time Apple changes some syscall?

Re: Linux System Call Table

#54

Post by shub »

throwaway613834 wrote: post #11

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

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.

Re: Linux System Call Table

#57

Post by leni536 »

Skunkleton wrote: post #37
tomsthumb wrote: post #34

Earlier quoted context omitted.

why bother with git grep vs. just vanilla grep. i could see the use if you're working with an older binary, but you didn't mention.

If you ran something like grep -r SYSCALL_DEFINE. read from the top level of the linux source it would search through not just your source code, but also all of the artifacts of building the kernel. Basically, git grep is faster in this case because it filters the searched files down to only ones that are checked in. You could achieve a similar effect with standard tools like this: find -type f -regex '. \.[hc]' | xa…

    grep -r --include='*.[hc]' 'SYSCALL_DEFINE.*read'

Re: Linux System Call Table

#58

Post by legulere »

int_19h wrote: post #52
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

Looking at this bug, it seems that Go has "fixed" it by fixing the syscall arguments, not by switching to libc. Did they switch to libc since then? If not, and given that Go apps are normally statically linked, does this mean that any precompiled Go app basically has a time bomb, in a sense that it'll break next time Apple changes some syscall?

The problem go has is that there’s a rather large overhead for calling C functions [1]. So they did not switch to calling libc as far as I know. And yes the next time Apple changes the syscalls, it will break again.

[1]: https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsg...

Re: Linux System Call Table

#60

Post by bmn__ »

Skunkleton wrote: post #37
tomsthumb wrote: post #34

Earlier quoted context omitted.

why bother with git grep vs. just vanilla grep. i could see the use if you're working with an older binary, but you didn't mention.

If you ran something like grep -r SYSCALL_DEFINE. read from the top level of the linux source it would search through not just your source code, but also all of the artifacts of building the kernel. Basically, git grep is faster in this case because it filters the searched files down to only ones that are checked in. You could achieve a similar effect with standard tools like this: find -type f -regex '. \.[hc]' | xa…

See also: programmer's grep clones. https://beyondgrep.com/more-tools/#Other%20grep-like%20tools

They work fine even where git-grep is not an option. Example:

    ack 'SYSCALL_DEFINE.*read'
Post reply on HN