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

[Florian Weimer <fweimer at redhat dot com>]

* Zack Weinberg:

> On Fri, Jun 28, 2019 at 5:35 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Dmitry V. Levin:
>>
>> > 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;
>>
>> I think this makes a lot of sense.  We should also do this for existing
>> constants (and for fcntl, too).  Perhaps after we have added more of the
>> wrappers that are *completely* missing, though.
>
> Yeah, I like this idea as well.  I think we should keep exposing the
> multiplexed interfaces, though, just because sometimes they do add new
> opcodes (e.g. the OFD locks).

Maybe.  But not as varargs functions, so that there's no ambiguity how
many arguments need to be extracted and passed to the system call (which
caused interoperability problems with open/openat).

Thanks,
Florian