3 ms·
> the ABI boundary chosen was well above the kernel as that is an easier place to define and maintain it. How do we actually know that placing the boundary abo
by loup-vaillant 4y ago
> the ABI boundary chosen was well above the kernel as that is an easier place to define and maintain it.
How do we actually know that placing the boundary above the kernel makes it easier to define and maintain?
- dataflow 4y agoOne reason (may not be their main one) could be that system calls have more overhead than function calls, and some things (like futexes) make more sense to implement on the userspace side. As another example, imagine a function for measuring time. You don't want that to be a system call if it's meant to be efficient, and when a better mechanism comes along, changing the implementation on the user space side is a lot easier and potentially more efficient if the kernel interface can be changed without breaking compatibility.
- bell-cot 4y agoQuip: The higher up the rug, the more crap that there's room to sweep under it. Or: Life can be easier for the kernel team if they're allowed to make breaking changes. Then task the lib team with writing shims / wrappers / etc. to fix all the problems which that causes. Then the manager of the lib team may have a perfect reason to boost his headcount. Then...
- Someone 4y agoIt makes it possible to change the API of system calls or completely remove them if better ideas come along for implementing their functionality. Without it, you end up maintaining system calls that nobody should use. Now, you could argue that moves the mess to the c library, which would still have deprecated functions that used to call old system calls, but now are built on top of better ones, but there’s more flexibility there. Application programmers can, one by one, move to newer c libraries that remove that cruft.