alt Hacker NewsI'm just noting this because it makes the number of Linux syscalls seem very exaggerated at a whole around 400 syscalls.
But, anyways, not like it matters that much but still.
400 distinct syscalls is a very large number of syscalls if you generally presume they're entirely distinct.
Replies
> 400 distinct syscalls is a very large number of syscalls
https://github.com/hfiref0x/SyscallTables
https://github.com/j00ru/windows-syscalls
And does the number matter? Why can't it be 1000, 2000, 4000. In my opinion the interface is free to be defined as long as it is documented properly.
Well, there really is about 400 syscall numbers allocated, and each has its own entrypoint in the kernel. That's an entirely objective criterion as opposed to arguing "well, sbrk and mmap (or recv and read) are kinda similar, maybe we should count them as just one syscall instead of two", because in the end we can might as well say "well, technically there is only one syscall, it just has an additional seventh argument that serves as the 'function denominator', like the ioctl's request parameter, you know".
I think the number is mostly meaningless even if we ignore whether they're distinct or not. Consider ioctl() - it's a single syscall but if I remember correctly the number of subcommands is in the thousands.
The number of Linux syscalls depends on the architecture and on x86-64 there are over 450 Linux syscalls.
Nonetheless, about one third of those syscalls are obsolete (being replaced by newer improved syscalls), even if a large number of programs are still using them, and about one other third of them are rarely used in the environments familiar to most Linux users, like personal computers and small servers.
The obsolete syscalls inflate a lot the number of Linux syscalls, because there are a lot of syscalls that were originally defined with an inadequate set of parameters, then they were fixed by adding parameters or changing the meaning of the existing parameters. There are many syscalls were even 3 or 4 attempts were needed until reaching an acceptable definition for their parameters.
New programs should use only the newest improved syscalls, but the documentation of the Linux syscalls in various places is usually not up-to-date itself, so a lot of people are still using older syscalls, without being aware that they are suboptimal. So the obsolete syscalls will have to be supported forever by the Linux kernels (though in most cases when an obsolete syscall is invoked it just fills the parameters with adjusted values and then it jumps to the current syscall).