I first released those in back in 2020 and now I finally added more architectures, Kernel selector, syscall descriptions and a few other niceties. It should work a bit better on mobile devices too but I am no CSS expert.
The API is at https://api.syscall.sh
ReDress•45m ago
Does it still make sense to term or classify them as two distinct syscalls?
rustyhancock•36m ago
guitmz•32m ago
rustyhancock•16m ago
PhilipRoman•32m ago
ReDress•28m ago
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.
PhilipRoman•11m ago
adrian_b•5m ago
Moreover, for a large number of traditional Linux syscalls there are now better alternatives that are invoked as subcommands of a single syscall: io_uring_enter.
adrian_b•9m ago
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.