Re: [PATCH RFC 0/9] Launching processes with io_uring

[Askar Safin <safinaskar@zohomail.com>]

Pavel Begunkov:
> At this point it raises a question why it even needs io_uring
> infra? I don't think it's really helping you. E.g. why not do it
> as a list of operation in a custom format instead of links? That
> can be run by a single io_uring request or can even be a normal
> syscall.

> Makes me wonder about a different ways of handling. E.g. why should
> it be run in the created task context (apart from final exec)? Can
> requests be run as normal by the original task, each will take the
> half created and not yet launched task as a parameter (in some form),
> modify it, and the final exec would launch it?

I totally agree. I think API should look like this:

===
// This may be PID fd or something completely different
int fd = create_task ();

task_manipulate (fd, OP_CHDIR, "/");
task_manipulate (fd, OP_CLOSE, 0);
task_manipulate (fd, OP_OPEN, "/dev/null", O_RDONLY, 0666);

task_execve (fd, "/bin/true", argv, envp);
===

We will have ability to do proper error handling.

Paper "A fork() in the road" says the same thing.
( https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf ).

From that paper:

> While a spawnlike API is preferred for most instances of starting a new
> program, for full generality it requires a flag, parameter, or
> helper function controlling every possible aspect of process
> state. It is infeasible for a single OS API to give complete
> control over the initial state of a new process. In Unix today,
> the only fallback for advanced use-cases remains code executed
> after fork, but clean-slate designs [e.g., 40, 43] have
> demonstrated an alternative model where system calls that
> modify per-process state are not constrained to merely the
> current process, but rather can manipulate any process to
> which the caller has access. This yields the flexibility and
> orthogonality of the fork/exec model, without most of its
> drawbacks: a new process starts as an empty address space,
> and an advanced user may manipulate it in a piecemeal fashion,
> populating its address-space and kernel context prior to
> execution, without needing to clone the parent nor run code
> in the context of the child. ExOS [43] implemented fork in
> user-mode atop such a primitive. Retrofitting cross-process
> APIs into Unix seems at first glance challenging, but may
> also be productive for future research

So, yes, such APIs already exist in research operating systems.

Moreover, as well as I understand, Windows NT native API also
creates processes the same way.

Askar Safin