On Tue, 1 Feb 2005, Bill Davidsen wrote: > Tim Schmielau wrote: > > The ppid of a process is not really helpful if I want to reconstruct the > > real history of processes on a machine, since it may become 1 when the > > parent dies and the process is reparented to init. > > > > I am not aware of concepts in Linux or other unices that apply to this > > case. So I made up the "biological parent pid" bioppid (in contrast to the > > adoptive parents pid) that just never changes. > > Any user of it must of course remember that it doesn't need to be a valid > > pid anymore or might even belong to a different process that was forked in > > the meantime. bioppid only had to be a valid pid at time btime (it's > > a (btime, pid) pair that unambiguously identifies a process). > > I think you are not only using a hammer to swat a fly, buy the wrong > fly. Would it not do as well to log reparenting? You could even add that > as an option to init, although if you are being lazy about tracking the > original parent a kernel log saying something like > reparent PID1 from PID2 to PID3 > would be best. While I think all current reparenting is done to init, I > could certainly think of a use for a method to reparent back to the > grandparent, just to keep the accounting clean.
My idea of a hammer seems to be slightly different. After all, I just added _two_lines_ of code [*] to log useful information where useless info was logged before. Any new logging mechanism would be orders of magnitude more expensive. Tim [*] or, in other word, 4 bytes per task_struct and one instruction to fill that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
