History of syscalls added to Linux?

Question

Is there anywhere I can get a complete list of the minimum version of Linux needed for each syscall? I'm looking for a general answer to questions of the form "If I use syscall X, what is the minimum version of Linux on which my code can run?"

you mean the minimum version of linux on which the call will run with the specified parameters and with the expected behavior? *evil grin* — Karoly Horvath, Jul 22 '11 at 23:23
I meant the minimum version with which the syscall will not return `ENOSYS` or whatever it does for invalid syscall numbers. I understand that some syscalls had incomplete or broken behavior in earlier versions, so info on that would be nice too, but beyond the scope of my original question. :-) — R.. GitHub STOP HELPING ICE, Jul 22 '11 at 23:44
If this is to be actually used, also an errata would be good to have. "Implemented" is not always the same as "implemented and decently working". — Prof. Falken, Feb 15 '12 at 10:48
@AmigableClarkKant: Yeah, but if you look at my questions, (almost?) all of the ones with no accepted answer are really hard questions that either don't have a solution yet, or where there are multiple conflicting opinions as answers and no authoritative sources. :-) — R.. GitHub STOP HELPING ICE, Feb 15 '12 at 16:29

score 32 · Accepted Answer · answered Feb 10 '12 at 06:48

32

This information can be found in the syscalls(2) manual page. For those system calls where no kernel version is indicated, the system call appeared in kernel 1.0 or earlier.

answered Feb 10 '12 at 06:48

mark4o

58,919
18
87
102

3

So far this is looking like the best answer. Don't know how I missed this to begin with. – R.. GitHub STOP HELPING ICE Feb 11 '12 at 23:24

score 9 · Answer 2 · answered Jul 23 '11 at 00:07

9

Linus has long criticised userspace checking for particular kernel versions to know if a feature is available - the recommended approach is instead to test for the feature you want (unimplemented syscalls do return ENOSYS).

One reason for this is that version numbers simply don't mean as much as they seem to - distributor kernels, which most users are actually running, often have features backported from newer kernel versions. Some of them are real Frankenstein's monsters in this respect.

answered Jul 23 '11 at 00:07

caf

233,326
40
323
462

7

My reason for asking is not to check if a feature is available at runtime, but to estimate whether I'm locking myself out of supporting versions that might be relevant by depending on certain syscalls. – R.. GitHub STOP HELPING ICE Jul 23 '11 at 00:19

score 4 · Answer 3 · answered Jul 22 '11 at 23:28

4

You can find this when using sites such as http://linux.die.net/ near the bottoms of the pages for the API calls, in the 'Version' section. For example inotify was added at Linux 2.6.13.

For posix calls this wont apply because they are gathered under Posix specifications, e.g. read has a 'Conforming' section mentioning POSIX.1-2001.

answered Jul 22 '11 at 23:28

Karl Mutch

63
6

2

Indeed, the one I was looking for right now was `clock_gettime` whose man page does not specify. – R.. GitHub STOP HELPING ICE Jul 22 '11 at 23:46

score 2 · Answer 4 · answered Feb 11 '12 at 14:35

There is a list of syscalls at the file include/asm-generic/unistd.h. You can check the history of that file at:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=history;f=include/asm-generic/unistd.h;h=2292d1af9d705f129ae523ce00a6b7794fb1648c;hb=8df54d622a120058ee8bec38743c9b8f091c8e58

I'm not sure about syscalls for other arch than x86. There may be details.

History of syscalls added to Linux?

4 Answers4