Linux: do syscalls change?

 

Syscalls are the user-space facing interface of the kernel. A user process usually does not call them directly but use libc to do that. libc either just provides a thin wrapper around the syscall or does some more work as in the case of fork() and exec()

So my question is - does the syscall interface to the kernel ever change between versions of the kernel in a non-backwards compatible way? Or is it once a syscall is established, it will never change?

A syscall is, from the application code perspective, an elementary atomic operation (it is a "virtual machine instruction"). See also syscalls(2).

The ABI specifies how exactly it is happenning. For x86-64 you can find it here. See also x86 calling conventions.

For some syscalls, recent kernels provide the vdso(7) to make them faster.

The Linux kernel tries hard to keep compatibility at the binary level. It is rumored that a 15 years old (statically linked) ELF executable should run unchanged on the most recent kernels.

However, in practice, you don't directly do syscalls in your code (because you need to do that in assembly, see Linux assembly howto). You very often use some libc for that (eg the GNU libc, or the MUSL libc). For several good reasons you generally dynamically link your program to libc.so . Then you might have -in the very long run- some incompatibilities issues (some binary programs linked to an old libc might not run with a much newer -or much older- one).

Big changes aren't to be expected because of the following reasons:

  • Although they will be called mostly through the libc, the libc can be changed - it created compatibility problems between the kernel and the libc versions, which needs to be avoided.
  • Syscalls are standardised exactly as the libc calls.

    • The libc version of fork() and exec() is really small, they to exactly as the syscalls. Maybe you are thinking on system() , which practically fork-s, calls a shell with exec and waits its termination.

    There are also syscalls with much lower importance, they aren't really liked by Linus and the core team, for example the syscalls starting with _reiser4... , they have much bigger chance to change in the future.

    But the standard syscalls, for example sys_open , sys_close , etc. won't change in the nearest future.

    There is also one thing, which can change, and it is not the syscalls, but the method how can be called. In the ancients, linux/i386 used this by an int 0x80 , where the number of the syscals had to put in eax . Since then came better/faster solutions for this as well, for example there is a CPU-specific SYSENTER asm-opcode, which also can be used. Their usability is cpu-specific, thus it was one of the first times, when the kernel needed to provide the user space code, how can be its syscalls called. If you type a cat /proc/$$/maps , you will see at end a [vdso] or a [vsyscall] memory area, this is. Older kernels (maybe before 2.4?) didn't have it.

    链接地址: http://www.djcxy.com/p/90876.html

    上一篇: 自定义linux内核的系统调用包装函数

    下一篇: Linux：系统调用改变了吗？