> On Sep 13, 2018, at 1:07 AM, Florian Weimer <fwei...@redhat.com> wrote:
>
> On 09/12/2018 07:11 PM, Andy Lutomirski wrote:
>>> The multiplexer interfaces need much more surgery and talking about futex,
>>> we'd need to sit down with quite some people and identify the things they
>>> actually care about before just splitting it up and keeping the existing
>>> overloaded trainwreck the same.
>>>
>> There’s also the issue of how much the speedup matters. For futex, maybe a
>> better interface saves 3ns, but a futex syscall is hundreds of ns.
>> clock_gettime() is called at high frequency and can be ~25ns. Saving a few
>> ns is a bigger deal.
>
> My concern is that the userspace system call wrappers currently do not know
> how many arguments the individual operations take and what types the
> arguments have (hence the “type-polymorphic” nature I mentioned). This could
> be a problem for on-stack argument passing (where you might read values
> beyond the end of the stack, and glibc avoids that most of the time by having
> enough cruft on the stack), and for architectures which pass pointers and
> integers in different registers (like some m68k ABIs do for the return value).
>
>
Isn’t clock_gettime already special because of the vDSO entry point, though?
