

Linux-insides: System calls in the Linux kernel, Part 2 - 0xAX
https://github.com/0xAX/linux-insides/blob/master/SysCall/syscall-2.md

======
amluto
I'm in the process of rewriting basically all of the 32-bit syscall code and a
decent amount of the 64-bit code. Enjoy!

~~~
Someone
1\. Why?

2\. (How) will you keep the interface compatible?

~~~
caf
As I understand it, the aim is to move as much of it as possible into C
(rather than asm). Ultimately this should make it more maintainable, and lessy
buggy.

Backwards compatibility is a given.

~~~
Someone
Less buggy in the sense of "bugs make it into a release" or less prone to
regressions that get discovered soon? I would the former, but would be
interested in an example of the latter.

Also, I would guess that also runs the risk of making it less portable across
compilers (you need non-standard compiler features to implement this in C). Is
that a concern?

~~~
amluto
> Also, I would guess that also runs the risk of making it less portable
> across compilers (you need non-standard compiler features to implement this
> in C). Is that a concern?

Actually, no. My code implements just enough in asm that the C part is a
normal function using the normal C ABI.

There are some microoptimizations that would be possible if I were to rely on
__builtin_frame_address, but GCC has some highly questionable optimizations
(or arguably outright bugs) that make me quite nervous about using it.

------
dnautics
Does anyone know why syscall variables are loaded into registers in linux
instead of left on the stack (as in freebsd, iirc)?

My guess would be performance... If that's the case has anyone benchmarked
that?

------
oso2k
This seems a lot more complicated than what I implemented in rt0 [0].

[0] [https://github.com/lpsantil/rt0](https://github.com/lpsantil/rt0)

~~~
caf
This is describing the kernel side of the syscall boundary, though.

