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

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

On Thu, Jun 27, 2019 at 11:22:45PM +0200, Florian Weimer wrote:
> * Dmitry V. Levin:
> > 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.

What if we start adding separate functions for new interfaces of already
existing multiplexed system call wrappers?

For example, ptrace is going to gain a new command (PTRACE_GET_SYSCALL_INFO)
in Linux 5.3.  My initial plan was just to update sys/ptrace.h with a new
constant and bits/ptrace-shared.h with a new structure, but I could add
a new function as well:

extern int ptrace_get_syscall_info (__pid_t __pid,
				    struct __ptrace_syscall_info *__infop)
	__THROW;


-- 
ldv

Attachment: signature.asc
Description: PGP signature