3 ms·
What's at issue here is linking to the platform libc for syscalls. If you don't want to use the platform libc's qsort implementation, by all means, don't. But i
by twic 4y ago
What's at issue here is linking to the platform libc for syscalls. If you don't want to use the platform libc's qsort implementation, by all means, don't. But if you want to call gettimeofday, you should do that by calling the gettimeofday function in the libc, not by trying to set up a system call on your own. The former is a stable interface, the latter isn't.
It's annoying that libc combines two completely different things - userspace utility functions, system calls - but unfortunately, that's where history has brought us.
- matheusmoreira 4y ago> But if you want to call gettimeofday, you should do that by calling the gettimeofday function in the libc, not by trying to set up a system call on your own. The former is a stable interface, the latter isn't. Not on Linux. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/stable/syscalls https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The system call interface is not only stable but also language agnostic. The correct place for this inferface isn't in some C library, it's in the language itself. We could have compilers directly targeting this. GCC could add a system_call keyword that emits code conforming to that ABI. Dynamic languages could have a JIT compiler that does the same thing.
- comex 4y agoEven on Linux, userland programs are encouraged to perform syscalls through the vDSO, a mini userland library supplied by the kernel. Performing syscalls directly is supported, but the vDSO is preferred. For most syscalls, using vDSO simply allows the kernel to pick the fastest available method for entering the kernel. But for a handful, the vDSO provides an optimized implementation that doesn't enter the kernel at all. One of those, ironically, is gettimeofday. That said, the vDSO is much smaller than any libc.