This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, Jun 27, 2019 at 11:57:46AM -0400, Zack Weinberg wrote: > On Thu, Jun 27, 2019 at 5:39 AM Dmitry V. Levin wrote: > > > > On Wed, Jun 26, 2019 at 05:04:52PM -0400, Carlos O'Donell wrote: > > [...] > > > Could you please review the language here: > > > https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers > > > > I suggest adding that there is no need to add wrappers for those syscalls > > that already have dedicated libraries. > > > > For example, such multiplexers as bpf(2) and keyctl(2) already have > > dedicated libraries (libbpf and libkeyutils, respectively) that provide > > APIs on top of these raw syscalls. > > I specifically disagree with this. The existence of these dedicated > libraries does not mean that there is no need for a minimal wrapper in > the C library. In fact, providing a minimal wrapper in the C library > would make the implementation of dedicated libraries easier, since > they can concentrate on designing their higher-level API rather than > wasting engineering effort on system call wrappers. glibc has already > done all of the low-level work necessary. > > I am a little disappointed to see that Linux is still inventing new > multiplexed system calls, though. I thought that was demonstrated to > be a bad idea back in the days of __NR_ipc. Speaking of multiplexed syscalls, if we don't event contemplate an idea of adding a glibc wrapper for __NR_ipc, why would we want to add a wrapper for __NR_bpf or __NR_keyctl? Since these syscalls have interfaces explicitly designed to scare regular users off and encourage them to use library functions instead, providing glibc wrappers for them would mislead people into invoking these system calls directly. These wrappers would lack type checking available in higher-level library functions, causing unnecessary runtime errors that are easily avoidable at compile time when higher-level library functions are used. Can you demonstrate any potential usefulness of glibc wrappers for __NR_bpf and __NR_keyctl? -- ldv
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |