Hmm, I like that idea. But I was talking about current implementation.
If we want to do this then we'd need to fix up every ptrace
implementation in every architecture to call the appropriate function;
it's a separate problem.
> > > this splitup of the lists makes it possible for the debugger to do a wait4
> > > that will get events from the debugged task, and for the debugged task to
> > > also be available to the real parent.
> >
> > Great. I'm not exactly sure on how this works right now: sys_wait4 only
> > iterates over ->children, with the exception of the special code in
> > TASK_ZOMBIE. I'm not quite sure when events from a traced process get
> > to the normal parent of that process, or when they're supposed to.
>
> i'm not sure about this either. What happens if an (untraced) parent has
> traced and untraced children, and does a wait4. Would it confuse the
> debugger if the parent could get one of the traced tasks as a result in
> wait4? And how does the debugger solve this problem?
Well, it seems to me that when a traced task has an event, it should be
reported first to the debugger - for signals this happens in do_signal
- and then possibly to the normal parent. But I'm not sure if this
actually happens right now or not. Worth investigating some more.
-- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/