Matt Helsley <matthltc@xxxxxxxxxx> writes: > On Mon, Oct 19, 2009 at 05:47:43PM -0400, Oren Laadan wrote: >> >> >> Daniel Lezcano wrote: >> > Sukadev Bhattiprolu wrote: >> >> Daniel Lezcano [daniel.lezcano@xxxxxxx] wrote: >> >> >> >>> Sukadev Bhattiprolu wrote: >> >>> >> >>>> Subject: [RFC][v8][PATCH 0/10] Implement clone3() system call >> >>>> > > <snip> > >> > Another point. It's another way to extend the exhausted clone flags as >> > the cloneat can be called as a compatibility way, with cloneat(getpid(), >> > 0, ... ) >> >> Which is what the proposed new clone_....() does. > > Just to be clear -- Suka's proposing to extend the clone flags. However I > don't believe reusing the "pid" parameters as Daniel seemed to suggest > was ever part of Suka's proposed changes. > > <snip> > >> > I don't really see a difference between sys_restart(pid_t pid , int fd, >> > long flags) where pid_t is the topmost in the hierarchy, fd is a file >> > descriptor to a structure "pid_t * + struct clone_args *" and flags is >> > "PROCTREE". > > I think the difference has to do with keeping the code maintainable. > > Clone creates the process so it's already involved in allocating and > assigning pids to the new task. Switching pids at sys_restart() would > add another point in the code where pids are allocated and assigned. > This suggests we may have to worry about introducing new obscure races > for anyone who's working on the pid allocator to be careful of. At > least when all the code is "localized" to the clone paths we can be > reasonably certain of proper maintenance. > > <snip> > >> I really really really hope we can settle down on *a* name, >> *any* name, and move forward. Amen. > > clone3() seemed to be the leading contender from what I've read so far. > Does anyone still object to clone3() after reading the whole thread? I object to what clone3() is. The name is not particularly interesting. The sanity checks for assigning pids are missing and there is a todo about it. I am not comfortable with assigning pids to a new process in a pid namespace with other processes user space processes executing in it. How we handle a clone extension depends critically on if we want to create a processes for restart in user space or kernel space. Could some one give me or point me at a strong case for creating the processes for restart in user space? The pid assignment code is currently ugly. I asked that we just pass in the min max pid pids that already exist into the core pid assignment function and a constrained min/max that only admits a single pid when we are allocating a struct pid for restart. That was not done and now we have a weird abortion with unnecessary special cases. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
