Re: glibc at the Toolchains microconference at LPC 2019

["Dmitry V. Levin" <ldv at altlinux dot org>]

On Thu, Jun 27, 2019 at 10:05:24AM +0000, Szabolcs Nagy wrote:
> On 27/06/2019 10:39, 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.
> 
> there are many issues doing raw syscalls e.g.
> the x32 type mess or cancellation support.

Yet raw syscalls have always been in use and this is not going to change.
If there are issues, we should consider providing appropriate interfaces
for invoking raw syscalls without these issues.

> external library projects can have different level
> of quality, supported abis, header conformance,
> security process etc. and they almost always mix
> libc and linux uapi headers and types.

This is all true but ...

> so i'm against relying on external libraries
> doing raw syscalls (they may provide additional
> functionality but the syscall itself should
> be in libc)

... some syscalls seem to have interfaces explicitly designed to scare
regular users off and encourage them to use library functions instead.
bpf(2) and keyctl(2) are examples of such interfaces, providing glibc
wrappers for them would mislead people into invoking these system calls
directly.


-- 
ldv

Attachment: signature.asc
Description: PGP signature