On Mon, Jun 08, 2026 at 05:01:57PM -0700, Andy Lutomirski wrote: > On Thu, May 28, 2026 at 4:05 AM Christian Brauner <[email protected]> wrote: > > > > On Thu, May 28, 2026 at 05:52:21PM +0800, Li Chen wrote: > > > Hi, > > > > > > This is an early RFC for an idea that is probably still rough in both the > > > UAPI and implementation details. Sorry for the rough edges; I am sending > > > it now to check whether this direction is worth pursuing and to get > > > feedback on the kernel/userspace boundary. > > > > The idea of having a builder api for exec isn't all that crazy. But it > > should simply be built on top of pidfds and thus pidfs itself instead. > > It has all the basic infrastructure in place already. Any implementation > > should also allow userspace to implement posix_spawn() on top of it. > > > > fd = pidfd_open(0, PIDFD_EMPTY /* or better name */) > > > > pidfd_config(fd, ...) // modeled similar to fsconfig() > > > > After contemplating this for a bit... why pidfd? Doesn't a pidfd > refer to an actual process that is, or at least was, running? This > new thing is a process that we are contemplating spawning. I can > imagine that basically all pidfd APIs would be a bit confused by the > nonexistence of the process in question.
I don't think that would be a problem because every api just needs to handle ESRCH. Ignoring that for a second: the mount api has a builder fd that is later transformed into a pidfd. Which is easily doable here as well. My point is that all the infrastructure building blocks already exist in pidfs.
