Re: [RFC] "biological parent" pid

[Tim Schmielau]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/