According to this system calls table, linux system calls are different across architecture, but IMO syscalls are higher level encapsulation which do not depent on any specific architechture. Why is it designed this way?
In a specific case, riscv64 linux doesn’t have mkdir, instead it has mkdirat, but weirdly it doesn’t have rmdir or rmdirat, how could it implement /bin/rmdir without rmdir, even if it could (via other syscalls like read and write), why not do the same for mkdir? It’s really confusing that these two syscalls don’t match.
>Solution :
You’re looking at this from the wrong direction. mkdirat can do everything that mkdir can do and then some, so the question isn’t why riscv64 doesn’t have mkdir, but rather why x86 does have it. The answer to that is backwards userspace compatibility. Since Linux never breaks that, and mkdir existed first, it will exist there forever. But riscv64 never had it, so there are no userspace programs for it to break by not having it.
As for rmdir, the replacement for that isn’t rmdirat, but rather unlinkat with AT_REMOVEDIR. The same argument then applies to it.