Messages in this thread | | | Date | Mon, 6 Mar 2000 15:10:22 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Allow debuger to examine real parent |
| |
On 6 Mar 2000, Mike Coleman wrote: > > It doesn't. ps reports the tracing process as the parent, rather than > reporting the original parent as the parent. AFAIK, ps gets its info from > /proc, and you can verify that every occurrence of 'pptr' in the proc code is > 'p_pptr' (referring to the parent) rather than p_opptr (referring to the > original parent).
Hmm.. That's probably a bug. It would probably be best to export the original parent in the /proc setup, and make the "debugging parent" possibly visible some way (but the original parent should be the normal one).
> Although I'm the author of the patch, I don't think it's really the ultimate > correct solution to the problem. The correct solution, IMHO, is (within > userland) to always report the original parent in places where the parent is > currently being reported. This preserves the illusion that ptracing isn't > happening, for processes that don't care or need to know about it.
Indeed. I think that illusion should be maintained, and really only debugging should know about the so-called "real" parent.
The whole "re-parenting" thing was just a bad excuse for not re-doing the parent pointers entirely, and should probably be ripped out at some point. We should probably - get rid of "p_opptr" - make "p_pptr" always be the real parent (which is not to say the process that does "fork()" - "clone()" can just clone the real parent field too, obviously) - add a "p_debuggerptr" thing that is entirely new and ONLY used for debugging.
The reason for the re-parenting is obviously signal handling at exit time, but that's just such a special case that it's not really worth the confusion between "original parent" and "real parent". But it works, and this is code that nobody really likes to touch because it is so fundamental, so..
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |