Anything that can be userspace should be userspace

Anything that can be userspace should be userspace

I think this does need to be in kernelspace for both performance and functionality reasons.

The previous discussion that inspired this one was specifically about performance of code that spawns several helper processes, in the UNIX tradition of "do one thing and do it well." If the way to make things work is to run a userspace helper that then execs the actual userspace binary, that will make things strictly slower from the status quo.

On the functionality side, the only way you could have the userspace helper implement preserving/renumbering file descriptors is to have the helper inherit every single file descriptor and then choose which ones to close. This runs into the same problem as we currently have with the lack of O_CLOFORK, i.e., there is a period of time where another process on the system, marching at its own pace, has a file open because it happened to be open at the time that that process was spawned. Even if the parent process has since closed the file descriptor, the underlying file is still open. This impacts both things like when a flush to disk happens and also e.g. whether you can exec the file without running into ETXTBSY. A spawn-like syscall has the ability to atomically (from the perspective of userspace) create a new process that never has unwanted file descriptors open.

(I guess you can technically get this right in userspace if you have a clone flag that only preserves stdio, and you redirect stdio to a UNIX socketpair, and you pass fds over that socket and have the helper install them in the right places. But that is complicated, and I also recently learned that it fails if you compile a kernel without networking support since sockets are networking.)

We do already have fork/exec, which is actually very well designed under the constraint that you want all the complexity to be in userspace; it gets you full flexibility to run any syscall between fork and exec and to start with the entire parent process's state to borrow from as you wish. The goal of this new interface is to solve the problems that are unavoidable with that approach.

BTW, I think there is a somewhat stronger argument to move execve into userspace. The only thing that it does right now that you can't really do from userspace is set /proc/self/exe correctly. Other than that, the task of opening a file, mapping in the executable segments, unmapping everything currently in memory, and jumping to the start address is pretty straightforward from userspace, and there are both complexity and functionality arguments for moving ELF parsing out of the kernel. (The obvious downside is now you get fun cases like running a static or emulated binary that doesn't know how to parse the executables in /usr/bin. If this functionality is in the kernel, it's guaranteed to be available to all processes equally easily.)