On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote: > On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote: > > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote: > > >> > > >>> If the kernel provides a system call, libc should provide a C wrapper > > >>> for it, even if in the opinion of the libc maintainers, that system > > >>> call is flawed. > > >> > > >> It's not that simple, I think. What about bdflush? socketcall? > > >> getxpid? osf_gettimeofday? set_robust_list? > > > > > > What about them? Mentioning that these system calls exist is not in > > > itself an argument. > > > > But socketcall does not exist on all architectures. Neither does > > getpid, it's called getxpid on some architectures. > > So what? On systems on which a given system call does not exist, > attempts to link against that system call should fail, or attempts to > make that system call should fail at runtime with ENOSYS. That's > completely expected and unsurprising behavior, not some unavoidable > source of catastrophic confusion. I'm sorry but you've just said that getpid() must either be unavailable or fail on those architectures that provide no syscall with exactly the same semantics as getpid syscall. Nobody is going to use a libc that doesn't provide getpid() in a reliable way. If you really need a 1-1 correspondence between syscalls and C wrappers, there is syscall(3) with all associated portability issues. If you need something else, please be more specific, i.e. be ready to give a detailed answer about every syscall ever supported by the kernel, on every supported architecture. My first trivial question is, do you need C wrappers for __NR_epoll_create, __NR_eventfd, __NR_inotify_init, and __NR_signalfd syscalls? -- ldv
Attachment:
signature.asc
Description: PGP signature
