LWN: Comments on "System-call wrappers for glibc"

linux-abi list: typo?

corbet — Fri, 20 Sep 2019 19:08:17 +0000

Yes, of course; it's been fixed.

System-call wrappers for glibc

fw — Fri, 20 Sep 2019 17:58:20 +0000

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.

linux-abi list: typo?

fw — Fri, 20 Sep 2019 17:54:26 +0000

I assume that “linux-abi list” is a typo for “linux-api list”. (If not, that might explain something.)

System-call wrappers for glibc

hrw — Fri, 20 Sep 2019 15:26:50 +0000

If you want to see how different system call numbers can be you can take a look at my syscalls table.

I generate it around every -rc1 kernel release and often at final one.

System-call wrappers for glibc

jani — Fri, 20 Sep 2019 07:58:25 +0000

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

mfuzzey — Fri, 20 Sep 2019 06:47:05 +0000

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

epa — Fri, 20 Sep 2019 06:31:34 +0000

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

NHO — Fri, 20 Sep 2019 06:05:21 +0000

Ain't we running out of syscall numbers?

System-call wrappers for glibc

pj — Fri, 20 Sep 2019 03:14:15 +0000

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

quotemstr — Fri, 20 Sep 2019 00:41:35 +0000

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?