On 01/26, Linus Torvalds wrote: > > The problem is that anything that is based on reparenting and signals is > fundamentally a "one parent only" kind of interface. See? Indeed. signals + do_wait() is the horrible model. > So the reason I think using an fd is a good idea is _not_ because gdb > already uses an fd internally, but because it gives you a "connection" > between the debugger and debuggee that is not fundamentally limited to a > single controller. > > (It doesn't have to be a file descriptor, of course, but could be any kind > of other model that allows multiple connections. Yes. But then we need something which represents this connection in kernel: utrace_engine. Then we need something which allows multiple tracers to cooperate. Just for example, one tracer wants to resume the tracee, another tracer wants the tracee to be stopped. Utrace does this. And, since we should preserve the current ptrace, the tracers should cooperate with ptrace too. IOW, this quickly leads to the new abstraction layer, I think. And of course it is possible to implement this new model on top of utrace. Yes, utrace itself comes with utrace_engine_ops vector to implement "whatever you like", perhaps you dislike this part. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
