Re: wrappers for multiplexed syscalls (was Re: glibc at the Toolchains microconference at LPC 2019)

[Florian Weimer <fw at deneb dot enyo dot de>]

* Dmitry V. Levin:

> Speaking of multiplexed syscalls, if we don't event contemplate an idea
> of adding a glibc wrapper for __NR_ipc, 

I think someonme did argue for socketcall when the topic came up a
while back.

> why would we want to add a wrapper for __NR_bpf or __NR_keyctl?

We have wrappers for ioctl, fcntl, ptrace, prctl.  I suppose they
could serve as models.

We'll see what the future will bring on the Linux.  I expect that
system calls are now easier to wire up consistently across
architectures, so perhaps we will see fewer multiplexer system calls
in the future.  I suspect that, for architecture-independent features,
these multiplexers had the important property that a kernel
contributor wouldn't need to touch arch-specific code to add further
sub-calls, which made them very attractive if you want to roll out new
features relatively quickly.

Regarding fcntl, I did look into providing a type-safe version of it
using _Generic/__builtin_types_compatible_p/__builtin_choose_expr and
so on.  But then I realized that instead, we probably should have
separate fcntl_* functions for each sub-call, similar to what we did
for socketcall.  gnulib could easily provide high-quality
implementations for libcs which do not pick up on this idea.

So yes, I tend to agree that exposing wrappers is problematic.

> 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.

Right.  And fcntl isn't so different, actually.

Thanks,
Florian