On Wed, Dec 11, 2024 at 02:02:14PM +0000, Pavel Begunkov wrote: > 1) It creates a special path that tries to mimick the core > path, but not without a bunch of troubles and in quite a > special way. > > 2) There would be a special set of ops that can only be run > from that special path. The goal would be for the exec op to work just fine from the normal path, too, for processes that want to do the equivalent of "do several syscalls then exec to replace myself", rather than doing a fork/exec. The current implementation defers supporting exec on a non-clone ring, but I'd expect that limitation to be lifted in the future. > 3) And I don't believe that path can ever be allowed to run > anything but these ops from (2) and maybe a very limited subset > of normal ops like nop requests but no read/write/send/etc. (?) I would ideally expect it to be able to run almost *any* op, in the context of the new process: write, send, open, accept, connect, unlinkat, FIXED_FD_INSTALL, ring messaging, ... > 4) And it all requires links, which already a bad sign for > a bunch of reasons. In theory you don't *have* to have everything linked for a batch of operations like this, as long as it's clear what to run in the new task. > 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? Because, as mentioned above, the intention *is* to support almost any io_uring operation, not just a tiny subset.
