That person seems to completely miss the whole point of fork/exec model -- setup of the new process. For example, a frequent operation when forking is to redir

That person seems to completely miss the whole point of fork/exec model -- setup of the new process. For example, a frequent operation when forking is to redirect file descriptors: ret = vfork() if (ret == 0) { dup2(file, STDERR_FILENO); exec() How would that work with "sfork"? Would the old stderr value be somehow saved by sfork() and restored on exec()? What about signal mask, resource limits, CPU affinities, effective user ids, capabilities and all the other process-inherited context that Linux have? That syscall will be both very complex and error prone, as the new features are added. To make it even worse, there could be userspace copies of the state -- for example one might do "fclose(stderr)" in the child process... and that cannot be easily undone in the kernel. The last section of README, "Possible Implementation Using Unshare", shows the author have not thought about those use cases at all.