Hi Christian, Thanks a lot for your great review!
---- On Thu, 28 May 2026 19:02:53 +0800 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. Yes, that makes a lot more sense. I was staring too hard at the "hot executable" part and made the cache/template the API, which was probably the wrong thing to expose. Sorry about that. > Any implementation > should also allow userspace to implement posix_spawn() on top of it. That's so cool, and this is a really useful point. I had not thought about this as something that could sit under posix_spawn(), but that makes the target much clearer. It should be a generic exec/spawn builder first, and the agent use case should just be one user of it. > fd = pidfd_open(0, PIDFD_EMPTY /* or better name */) > > pidfd_config(fd, ...) // modeled similar to fsconfig() Reusing pidfd_open() with an empty target is nice because it keeps the API close to pidfds, but I wonder if a separate entry point such as pidfd_spawn_open() or pidfd_create() would make the "new process builder" case a bit more explicit? Either way, the configuration side being fsconfig-like makes sense to me. Thanks again for pointing me in this direction. It helps a lot. Regards, Li
