Right. pid == 1 being missing might cause some confusing having
but having ppid == 0 should be fine. Heck pid == 1 already has
ppid == 0, so it is a value user space has had to deal with for a
while.
In addition there was a period in 2.6 where most kernel threads
and init had a pgid == 0 and a session == 0, and nothing seemed
to complain.
We should probably make all of the kernel threads children of
init_task. The initial idle thread on the first cpu that is the
parent of pid == 1. That will give the ppid == 0 naturally because
the idle thread has pid == 0.
Almost everything should be using kthread by now. I do admit that there
are a handful of kernel threads that still use kthread_create but it
is a relatively short list.
Looking we apparently have a couple of process started by
kthread_create that are not under kthread. They all have pid numbers
lower than kthread so I'm guessing it is some startup ordering issue.
Currently it looks like daemonize is reparenting everything to init,
changing that to init_task and making the threads self reaping
should be trivial.
.....
I'm a little nervous that we exceeded our default pid max just booting
the kernel. 32768 is a lot of kernel threads. That sounds like 32
kernel threads per cpu. That seems to be more than I have on any
of my little machines.
There is no defined order for reaping of child processes and in fact
I can't even see anything in the kernel right now that would even
accidentally give user space the idea we had a defined order.
So I think we have some options once we get the kernel threads out
of the way. Getting the kernel threads out of the way would seem
to be the first priority.
Eric
-
