[jcranmer]

Calling that elegant is a path dependence of the history of fork+exec.

In an alternative world where fork+exec never existed, a lot of those "usual APIs" would probably have had an explicit pid argument to them that let you modify process configuration from a different process. (This is how Fuschia works, e.g.). There's a lot of benefit to this world: the most obvious is that you don't have to magic up some IPC system just to report configuration errors, but there's actually a good amount of utility in being able to have a manager process that is tweaking attributes of its children (e.g., debuggers would love it).

[trumpdong]

Or you could call ptrace_syscall (that doesn't currently exist) on your child processes that you are tracing because you'd always be tracing them by default, or get an io_uring for the child process, or...

[uecker]

A ptrace_syscall would be interesting and would seem to be a full replacement for having the pid argument everywhere.

But frankly, I am not really seeing the value.

[trumpdong]

The value is not needing to change every other syscall and not needing to write new ones with a pid argument (besides which, what when you want to change it to a pidfd argument? then you add pidfd_syscall instead of duplicating every syscall again)

[uecker]

I meant the value of running syscalls in another process from the parent process in contrast to (v)forking and running them in the child directly.

[trumpdong]

The value is starting the child with a clean slate instead of a copy of its parent.

[uecker]

Weren't there enough parallel paths of development in this world?