System-call wrappers for glibc

Posted Sep 20, 2019 0:41 UTC (Fri) by quotemstr (subscriber, #45331)
Parent article: System-call wrappers for glibc

I've long been of the opinion that the kernel should avoid multiplexing system calls. I've said repeatedly on lkml that system calls are not expensive and that multiplexers are pointless. Maybe I'll finally get some traction now?

System-call wrappers for glibc

Posted Sep 20, 2019 3:14 UTC (Fri) by pj (subscriber, #4506) [Link]

Even with normal APIs, it's a design issue of whether to have one call with a boolean flag or two calls that ends up boiling down to aesthetics at some point.

System-call wrappers for glibc

Posted Sep 20, 2019 6:05 UTC (Fri) by NHO (subscriber, #104320) [Link]

Ain't we running out of syscall numbers?

System-call wrappers for glibc

Posted Sep 20, 2019 6:31 UTC (Fri) by epa (subscriber, #39769) [Link] (2 responses)

If the multiplex call is wrapped by the C library then you can have a separate C function for each mode, each one with a sane and type-safe interface. System calls are a finite resource but C library interfaces are not. However, if you take the view that the C library should provide exactly the interface given by the kernel, a messy system call will result in messy user code.

System-call wrappers for glibc

Posted Sep 20, 2019 6:47 UTC (Fri) by mfuzzey (subscriber, #57966) [Link] (1 responses)

I would say the kernel and the glibc developers should work together *before* new syscalls are set in stone to, as far as possible, come up with a design that suites everyone and makes the wrappers simpler.

That may not be possible in every case for technical reasons but I think up to recently it was more of lack of communication between the kernel and glibc developers that caused most problems rather than specific technical issues.

System-call wrappers for glibc

Posted Sep 20, 2019 7:58 UTC (Fri) by jani (subscriber, #74547) [Link]

FWIW, this is what we try to do in the graphics subsystem for uapi. The userspace part needs to be agreed on and basically ready to merge in the relevant userspace upstream projects before the kernel part lands.

Details at https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#...

System-call wrappers for glibc

Posted Sep 20, 2019 17:58 UTC (Fri) by fw (subscriber, #26023) [Link]

I suspect that it's a side-effect that wiring up even completely architecture-independent system calls across all architectures used to be very complicated, so that system call additions tended to be spread across many kernel releases. With a multiplexer, you only have to go through the process once. Likewise for adding the system call wrapper to glibc.

Truly problematic are only system calls for which the intended implementation uses va_list in some way. The increased type safety may be worthwhile for separate functions, and it generally increases source portability once rarely used types change (e.g. file offsets with fcntl, times with futex). But that seems to be difficult to predict.