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]

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


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]