Uh, sorry, what? Trying to measure similarity between syscalls is a) impossible, b) pointless, so obviously I'd really like to understand why someone would want to do something like this — but I'd rather not speculate about what and why you think and believe, and instead to just straight hear from you.

If you're interested in why I think what I think — there's a sibling comment where I tried to articulate my position. I'd like to hear about yours, if you don't mind.

P.S. You didn't actually offer any argument, logical (?) or technical (?!), in your original comment, and I think you're actually have the meaning of those words reversed: "logical argument" appeals to logical relations between the abstract concepts, while "technical argument" appeals to the underlying technology (the kernel implementation in our case) and tries to deal with particularities of reality. So if anything, my argument was the logical (semantical?) one, not that it really matters.

▲

ReDress 7 hours ago | parent [-]

Yeah, sure, but the obvious fact that is a lot of syscalls are 'family' relatives.

And they wouldn't ever count as distinct syscalls.

▲

asalahli 6 hours ago | parent [-]

> they wouldn't ever count as distinct syscalls.

According to whom, exactly?

	▲	ReDress 6 hours ago \| parent [-]
		If a syscall morphs into several slightly variant syscalls, then there's no way these are distinct syscalls. If a syscall is designed to counter the flaws have been observed in another syscall, then there's no way this is a distinct syscall. If a syscall is designed to add feature to an another syscall, then there's no way this is distinct syscall. And so on and so forth. If you actually look at Linux kernel code, you will quickly note that a lot of these related syscall even happen to share a large amount of implementation code. So, yeah