>>> Philip Guenther 27-Feb-17 06:09 >>> : > I've now gone back and forth on this diff a few times. I like the > simplfication of allocpid(), but then it seems like deck-chair shuffling > as the test is just moved to another function. > > But eliminating the magic-at-a-distance randompid frobbing is nice, as is > making it clear that there's really only one PID that will ever be > special. Indeed, it would even allow kthreads to be created before init > (though what _else_ they depend on is unclear...). Maybe setting the USB > tasks loose earlier would be useful, for example. Hmm. > > Since I'm so mixed, do any other devs have an opinion?
I like the removal of the global randompid, and using a flag to ask for PID 1 is much better than the original proposal of specifying the PID. Since the bikeshed could always do with a new coat of paint, how about renaming allocpid() to randompid()? :) But you have an ok on the FORK_PID1 implementation and the man page change you suggest. Tom > > > --- a/share/man/man9/fork1.9 > > > +++ b/share/man/man9/fork1.9 > > > @@ -109,6 +109,9 @@ must also be set. > > > .It Dv FORK_PTRACE > > > The child will start with tracing enabled, as if > > > ptrace(PT_TRACE_ME, 0, 0, 0) had been invoked in the child. > > > +.It Dv FORK_PID1 > > > +Special flag to assign PID 1 for > > > +.Xr init 8 process. > > I think this would be a nice place to explicitly mention the default is a > random pid, perhaps: > .It Dv FORK_PID1 > The child is > .Xr init 8 > and is assigned PID 1 instead of a random PID. > > Philip
