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

61–65 of 65 posts

Re: Linux System Call Table

#61

Post by Manozco »

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

> 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?

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).

Re: Linux System Call Table

#62

Post by Skunkleton »

leni536 wrote: post #57
Skunkleton wrote: post #37

Earlier quoted context omitted.

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'

Nice. I hadn't used --include before.

Re: Linux System Call Table

#63

Post by int_19h »

legulere wrote: post #58
int_19h wrote: post #52

Earlier quoted context omitted.

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...

Wow. So, basically, Go is a rather insular ecosystem - since you're paying the overhead of a context switch for every single FFI call - and if you use the stock APIs, it's essentially broken by design on macOS (since it uses APIs that Apple itself does not consider stable).

That's really sad. I was just beginning to like some aspects of it.

Re: Linux System Call Table

#64

Post by int_19h »

Manozco wrote: post #61
int_19h wrote: post #49

Earlier quoted context omitted.

> 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?

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 s…

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.

Post reply on HN