Yes, the ioctl has been notorious for sneaking in arbitrary amount of functionality into the kernel space, and serving generally as a kitchen sink: "You can rarely convince Linus to make a new syscall, but making a new ioctl is much easier". That's still one syscall though.

And how do you even compare how the distinct the syscalls are (e.g., pipe() and open() are about 70% similar)? And after that, what do you do with this metrics? How do you sum it up? Again, pipe() and open() are 70% similar — does that mean we have 1.3 syscalls instead of 2?

▲

adrian_b 8 hours ago | parent [-]

I would count "pipe" and "open" together as 0 (useful) syscalls, because both have been obsolete for a very long time (even if they occupy 2 slots in the syscall table and those 2 slots will remain occupied forever).

These 2 syscalls have a history typical for Linux syscalls, where frequently new syscall variants make completely obsolete their predecessors, but the old syscalls must still remain supported forever by the newer Linux kernels, to allow running legacy programs.

"pipe" has been obsoleted by "pipe2" (on 2008-10-09), which in turn has been obsoleted by "IORING_OP_PIPE".

"open" has been obsoleted by "openat", which in turn has been obsoleted by "IORING_OP_OPENAT".

Most users do not invoke Linux syscalls directly, but they use the standard C library, which has frequently shielded the end user from the evolution of the Linux syscalls. For instance, you might use the functions "open()" and "pipe()" in your C program, but the C library might invoke instead of those the more modern syscalls "openat" and "pipe2", after adjusting their parameters.

▲

Joker_vD 7 hours ago | parent [-]

I think you're missing the point I'm trying to make. Both pipe2 and openat has about 70% similar functionality (and so do the IORING_OP_PIPE and IORING_OP_OPENAT operations) — really, the only difference is that pipe2 returns two new fds instead of just one, and that the file opened is not a regular file. So, are those 2 syscalls or 1.3? What about triples or quadruples of syscalls with overlapping functionality, do we go full inclusion-exclusion formula on them? What about that 70% similarity estimation — how do establish that? Do you count the similarity/overlap of the underlying implementations? Only of the user-facing functionality? Both, somehow? Something else entirely?

Or, you know, we can instead not engage in this subjective quagmire and look at the actual, factual number that undeniably exists. It may not be very useful for any practical purpose except for pointless dick-measuring between OSes with radically different APIs and internal architectures — but neither is this trying to measure syscall similarity, really.

	▲	smj-edison 4 hours ago \| parent [-]
		I think it's a bit unfair to mainly focus on the API surface while ignoring a lot of internal details. Linus has talked about how Linux will often have massive amounts of internal code change between releases, while the API surface stays the same. So yeah, the API might be old and crufty, but it's also been around for 30 years. And as long as the API is sufficient, it's the internals that are a lot more interesting. Radically redesigning the API every few years would just accelerate towards XKCD 927, because of backwards compatibility.