Re: glibc at the Toolchains microconference at LPC 2019

[Christian Brauner <christian at brauner dot io>]

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.
> 
> 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.
> 
> so i'm against relying on external libraries
> doing raw syscalls (they may provide additional
> functionality but the syscall itself should
> be in libc)

I agree.
Not just does the quality of those libraries often vary wildly.
Sometimes there are competing libraries and it is unclear which one is
properly maintained and which one is not. (A good example are the
capability libraries libcap2 and libcap-ng (or whatever it's called).)

I think that (g)libc should not make a judgement on whether or not a
syscall should be exposed apart from the caveats Carlos and Zack already
pointed out. It's a massive paintpoint for userspace if the only options
are: link against a (possibly unmaintained) library or do the raw
syscall yourself.

Christian